View MT92210_287684.PDF datasheet online --- IC-ON-LINE

Datasheet File OCR Text:

MT92210 1023 Channel Voice Over IP Processor
Data Sheet Features
* * * * * * * * * * * * * 1023 full-duplex PCM or ADPCM voice channels over IP/UDP/RTP connections RTP packaging optional in IP/UDP connection Supports IP version 4 and version 6 Supports IP over Ethernet, ATM (AAL5) or POS Support Ethernet II, IEEE 802.3, LLC/SNAP and PPP frames Supports Classical IP over ATM and LAN Emulation (LANE) v1/v2 Supports MPLS, MPOA and IEEE 802.1p/Q ELAN-ID H.110 compliant TDM bus carrying PCM, ADPCM or HDLC channels HDLC channels can be used to carry UDP payload generated by external agent Support trunking in RTP; up to 255 PCM/ADPCM channels per RTP connection Support maximum 1500 bytes packet size Up to 4096 bytes of jitter buffer, absorbing +/256 ms of PDV Less than 250 usec of latency
DS5828 Issue 2 December 2002
Ordering Information MT92210 608 Pin EPBGA
-40C to +85C * * * * * * * * Injection of CPU-generated RTP packets or AAL0 cells Reception of CPU-destinated RTP packets or AAL0 cells Primary and secondary network interfaces Primary network interface supports 10/100 MII, POS-PHY or Utopia level 1/2 Secondary network interface supports Utopia level 1 Proprietary Adaptive Silence Suppression Less than 2.5 watts of power 608 pin PBGA package
(8K to16.384M PLL)
M T9043
optional
Intel/M otorola CPU
MT92210 M essage Channel H110 Signals Com patibility Clocks and Frame Pad TDM DataPath H100/ H110 Interface Clock Recovery uP Interface Second Network Interface Primary Network Interface UTOPIA Port B (PHY/SAR) MII, POS, or UTOPIA (PHY/SAR interface
Service Timer
SS
RTP Assem bly RTP Disassembly
SS/Padding Calculator
Packet Identification and Routing
Dual M em ory Controler
Network Memory Controler
SSRAM (256k x18*) Mem ory Bank A
SSRAM (512k x18*) M em ory Bank B
SSRAM (256k x36*)
SDRAM (4M x32*)
Mem ory Bank C
*Typical RAM size for the support of 1023 channels. Parity bis are optionnal on all
Figure 1 - MT92210 Block Diagram
i
MT92210
Applications
* * * * * * High density voice gateway Voice over IP 3G and UMTS Network processor IP switching Voice over DSL/cable
Data Sheet
Description
The MT92210 device is a voice over IP/RTP assembly and disassembly engine that can convert up to 1023 fullduplex PCM voice channels or 4096 HDLC channels to IP packets and back, conforming to IETF RFC791 (IPv4), RFC2460 (IPv6), RFC768 (UDP) and RFC1889 (RTP). On one side, the device communicates with an H.110 TDM bus carrying voice in either PCM format, ADPCM or HDLC-encapsulated mini-packets; on the other side, it carries its packet data over Ethernet, ATM (using AAL5 cells) or Packet over SONET. A 16-bit Intel/Motorola CPU interface is used to access and configure the device. Finally, three external SSRAM banks and one external SDRAM bank are used for configuration and storage space.
Conventions
In this document, the following conventions are used: * * * * * * * * * * * * * The transmission direction and the abbreviation TX always refer to the direction in which voice is converted into IP packets. The reception direction and the abbreviation RX refer to the direction in which packets or cells are converted into PCM bytes or HDLC packets. All numbers in this document are decimal unless otherwise specified. Hexadecimal number can be identified by the `h' suffix (ex: A5h). Binary numbers are either in double quotes for multiple bits or in single quotes for individual bits (ex: "1001", `0'). The term "byte" means 8 bits. The term "word" means 16 bits. The term "dword" means 32 bits. The word "high" means a binary value of `1'. The word "low" means a binary value of `0'. The verb "to clear" means to reset one or multiple bits to `0' The verb "to set" means to put one or multiple bits to `1'. All addresses are specified in hexadecimal and point to bytes. Addresses are converted from bytes to words to double words using the little endian format, unless otherwise specified.
ii
Zarlink Semiconductor Inc.
Data Sheet
Colour Code
In this document, the following color code is used: * * *
MT92210
Fields in red are initialized by software when the structure is created, and are written back by the hardware. Fields in black are initialized by software when the structure is created, and are never written back by the hardware. Fields in dark yellow are initialized by software when the structure is created and are written back at the same value by the hardware. This shade denotes a Reserved Field. This shade denotes an Unimplemented Field. The field outlined in red is only written back by the chip when one of the bits, contained within the field and in red, was set and will then be cleared by the chip when it is done acting upon the set request bit.
Document Organization
This data sheet is divided into the following sections: * * * * * * * * * * * * * CPU Interface (Chapter 2.0) describes the main external interface of the MT92210 chip. Network Interface (Chapter 3.0) describes the interface to the 3 different types of link interfaces, Ethernet, UTOPIA, and Packet over SONET, that are supported. Link Layers (Chapter 4.0) describes the 3 different types of link layers, Ethernet, ATM AAL5, and Packet over SONET, that are supported. RX/TX Data Flows (Chapter 5.0) describes the data flows for all packets received and transmitted. Packet Identification (Chapter 6.0) describes the process by which packets are identified. Packet Assembly (Chapter 7.0) describes the collected bytes written in the circular buffers by the TX TDM, and how they are assembled into RTP packets. Packet Disassembly (Chapter 8.0) describes how RTP packets are transformed into PCM bytes, ADPCM samples, or HDLC/CPU-destined mini-packets. TX/RX TDM Data Paths (Chapter 9.0) describes the data paths for all bytes transmitted and received with the H.110 interface. H.110 Interface (Chapter 10.0) describes the compatibility of the TDM interface with the H.110 bus. Clocking (Chapter 11.0) describes the clocks used for the Network Interface and the SAR portion of the device. Pin-out is in Chapter 12.0. Electrical Characteristics (Chapter 13.0) describes the electrical characteristics of all the interfaces. Register List and Memory Map are contained in the MT92210 Design Manual.
Zarlink Semiconductor Inc.
iii
MT92210
Data Sheet
iv
Zarlink Semiconductor Inc.
Data Sheet Table of Contents
MT92210
Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .ii Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .ii Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .ii Colour Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii Document Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii 1.0 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 1.1 General Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 1.2 Data Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 1.3 Voice Treatment Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 1.4 Network Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 1.5 Silence Suppression and Padding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 1.6 H.110 Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 1.7 TDM data formats. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 1.8 Link Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.0 CPU interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.1 CPU Interface Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.2 CPU Interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.2.1 Example Interrupt Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.2.1.1 Interrupt Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.2.1.2 Interrupt Servicing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.3 Intel/Motorola Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.3.1 Extended Indirect Access Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.3.1.1 Extended Indirect Writes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.3.1.2 Extended Indirect Reads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.3.2 Extended Direct Access Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.3.2.1 Extended Direct Writes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.3.2.2 Extended direct reads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.4 MT92210 Reset Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 3.0 Network Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 4.0 Link Layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 4.1 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 4.2 Ethernet Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 4.3 Packet over SONET Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 4.4 UTOPIA Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 4.5 Packet Reassembly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 5.0 RX/TX Data Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 5.1 RX Data Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 5.2 TX Data Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 6.0 Packet Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 6.1 Packet Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 6.2 Packet Parsing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 6.3 Look-up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 6.4 Masking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 6.5 Post-search Confirmation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 7.0 Packet Assembly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 7.1 Service Timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 7.2 Event Queue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 7.3 RTP Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 7.3.1 TX RTP Header Structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 7.3.2 Header Length . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 7.3.3 Packet Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Zarlink Semiconductor Inc.
v
MT92210 Table of Contents
Data Sheet
7.3.4 Identification Counter Source Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 7.3.5 UDP Header Start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 7.3.6 Timestamp Offset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 7.3.7 Sequence Number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 7.3.8 Transmitted Packet Count . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 7.3.9 RTD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 7.4 PCM Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 7.4.1 Next TDM Write Pointer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 7.4.2 Valid Bit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 7.4.3 Buffer Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 7.4.4 TX Silence Suppression Structure Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 7.4.5 Extra Delay Frames. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 7.4.6 RTP Timestamp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 7.4.7 Circular Buffer Base Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 7.5 HDLC Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 7.6 Silence Suppression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 8.0 Packet Disassembly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 8.1 RTP Treatment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 8.2 xxPCM Treatment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 8.3 Packet Delay Variation (PDV) Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 8.4 HDLC Treatment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 8.5 CPU Treatment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 9.0 TX/RX TDM Data Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 9.1 TX TDM Data Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 9.2 TX TDM Data Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 9.3 RX TDM Data Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 9.3.1 RX TDM Data Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 10.0 H.110 Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 10.1 Slave Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 10.2 Bus Master Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 10.3 Polarities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 11.0 Clocking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 11.1 Programming the mem_clk_xxx PLL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 11.2 Clock Recovery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 11.3 Memory Controllers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 12.0 Pin-out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 13.0 Electrical Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 13.1 Absolute Maximum Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 13.2 Recommended Operating Conditions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 13.3 DC Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 13.4 Clock Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 13.5 AC Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 13.5.1 Intel/Motorola CPU Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 13.5.2 UTOPIA / POS-PHY / Ethernet Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 13.5.3 H.110 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 13.5.4 External Memory Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 Appendix B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 HDLC Format, Including Zero-Insertion and Extraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 Appendix C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 Standards & Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
vi
Zarlink Semiconductor Inc.
Data Sheet Table of Contents
MT92210
Appendix D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .185 Glossary of Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Zarlink Semiconductor Inc.
vii
MT92210 Table of Contents
Data Sheet
viii
Zarlink Semiconductor Inc.
Data Sheet List of Figures
MT92210
Figure 1 - MT92210 Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .i Figure 2 - Internal Interrupt Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Figure 3 - Network Interface Buffering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Figure 4 - Packet Block Memory and Format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Figure 5 - Packet Block Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Figure 6 - Packet Handler Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Figure 7 - Handle Queue and Handle Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Figure 8 - Basic Handle Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Figure 9 - Raw Cell Format (used cell) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Figure 10 - Raw Cell Format (free cell) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Figure 11 - Cell Handler Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Figure 12 - UTOPIA Look Up Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Figure 13 - UTOPIA LUT Entry Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Figure 14 - Location of Reassembly Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Figure 15 - Packet Reassembly Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Figure 16 - Rx Flow 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Figure 17 - Rx Flow 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Figure 18 - Rx Flow 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Figure 19 - Rx Flow 4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Figure 20 - Tx Flow 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Figure 21 - Tx Flow 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Figure 22 - Tx Flow 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Figure 23 - Tx Flow 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Figure 24 - Packet Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Figure 25 - Format of Initial Search Structure (Refer to Figure 19 for field descriptions). . . . . . . . . . . . . . . . . . . . 51 Figure 26 - Next Header Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Figure 27 - Identification Key Formats (before CRC). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Figure 28 - Profile Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 Figure 29 - Flow Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Figure 30 - Format of Profile Default Post-Search Structure (Refer to Table 19 for field descriptions). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Figure 31 - Binary Tree Node. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 Figure 32 - Post-Search Conformation Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 Figure 33 - Service Timer Control Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 Figure 34 - Assembly Event Queue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 Figure 35 - Assembly Event - Send HDLC RTP Packet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 Figure 36 - Assembly Event - Service xxPCM RTP Channel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 Figure 37 - Assembly Event - Send CPU RTP Packet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 Figure 38 - TX RTP Connection Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 Figure 39 - xxPCM Channel Addition to TX RTP Connection Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 Figure 40 - TX RTP Header Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 Figure 41 - TX Silence Suppression Structure: Internal VAD & White Energy Estimation . . . . . . . . . . . . . . . . . . . 81 Figure 42 - TX Silence Suppression Structure: Internal VAD & Spectral Energy Forwarding . . . . . . . . . . . . . . . . 82 Figure 43 - TX Silence Suppression Structure: External VAD & White Energy Estimation . . . . . . . . . . . . . . . . . . 83 Figure 44 - TX Silence Suppression Structure: External VAD & Spectral Energy Forwarding. . . . . . . . . . . . . . . . 84 Figure 45 - RX Disassembly Event Report Queue. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 Figure 46 - RX RTP Connection Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 Figure 47 - Payload Type/Marker Bit Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 Figure 48 - RX Disassembly Event Report Queue - RTP Connection Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 Figure 49 - RX RTP xxPCM Channel Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Zarlink Semiconductor Inc. ix
MT92210 List of Figures
Data Sheet
Figure 50 - RX Disassembly Event Report Queue - xxPCM Channel Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 Figure 51 - RTP Common PDV Absorption Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 Figure 52 - RX RTP HDLC Channel Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 Figure 53 - RX Disassembly Event Report Queue - HDLC / CPU Channel Report . . . . . . . . . . . . . . . . . . . . . . 105 Figure 54 - Rx CPU Buffer Control Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 Figure 55 - RX Circular Buffer Base and Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 Figure 56 - RX RTP CPU Channel Structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 Figure 57 - TX Channel Association Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .111 Figure 58 - Buffer Tag Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 Figure 59 - TX TDM Control Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 Figure 60 - TX Circular Buffer Base/Size Indication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 Figure 61 - TX Circular Buffer Base/SOP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 Figure 62 - HDLC Stream to HDLC Address LUT Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 Figure 63 - HDLC Address LUT (RTP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 Figure 64 - Format of TX xxPCM TSSTs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 Figure 65 - RX Channel Association Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 Figure 66 - Stream/Buffer Tag Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 Figure 67 - RX TDM Control Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 Figure 68 - RX Circular Buffer Base/Size Indication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 Figure 69 - RX HDLC Stream/Buffer Control Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 Figure 70 - RX Circular Buffer Base and Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 Figure 71 - Format of RX xxPCM TSSTs - 1 of 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 Figure 72 - Format of RX xxPCM TSSTs - 2 of 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 Figure 73 - CN Packet Conversion Lookup Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 Figure 74 - TDM Bus Timing - ct_d . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 Figure 75 - TDM Bus Timing - fr_comp Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 Figure 76 - TDM Bus Timing - sclkx2 Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 Figure 77 - TDM Bus Timing - Compatibility Clock Generation (other than sclk, sclkx2) . . . . . . . . . . . . . . . . . . 132 Figure 78 - Clock Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 Figure 79 - Adaptive Clock Recovery Event Queue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 Figure 80 - Adaptive Clock Recovery RTP Event Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 Figure 81 - Adaptive Clock Recovery Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 Figure 82 - GPIO Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 Figure 83 - Message Channel Circuit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 Figure 84 - PLL Noise Reduction Circuits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 Figure 85 - Non-multiplexed CPU Interface - Intel Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 Figure 86 - Non-multiplexed CPU Interface - Motorola Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 Figure 87 - Multiplexed CPU Interface - Intel Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 Figure 88 - Multiplexed CPU Interface - Motorola Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 Figure 89 - UTOPIA / POS-PHY / Ethernet Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 Figure 90 - H.110 Input Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 Figure 91 - H.110 Message Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 Figure 92 - External Memory Timing (both SSRAM and SDRAM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 Figure 93 - Supported RTP HDLC Packet Format (after zero extraction) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
x
Zarlink Semiconductor Inc.
Data Sheet List of Tables
MT92210
Table 1 - Indirect Access Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Table 2 - CPU Interface Mode Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Table 3 - Control Register (000h) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Table 4 - Read/Write Data Register (004h) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Table 5 - Address High Register (008h) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Table 6 - Address Low Register (00Ah) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Table 7 - Packet Block Format Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Table 8 - Handle Queue Descriptor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Table 9 - Fields and Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Table 10 - Fields and Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Table 11 - Fields and Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Table 12 - Fields and Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Table 13 - Packet Types and Initial Search Structures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Table 14 - Fields and Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Table 15 - Fields and Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 Table 16 - Fields and Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 Table 17 - Profile Default Post-Search Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 Table 18 - Fields and Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 Table 19 - Fields and Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 Table 20 - Fields and Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 Table 21 - Service Timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Table 22 - Fields and Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 Table 23 - Fields and Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 Table 24 - Fields and Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 Table 25 - Fields and Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 Table 26 - Fields and Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 Table 27 - Fields and Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 Table 28 - Fields and Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 Table 29 - Fields and Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 Table 30 - Fields and Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 Table 31 - Fields and Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 Table 32 - Fields and Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 Table 33 - Fields and Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 Table 34 - Fields and Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 Table 35 - Fields and Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 Table 36 - Fields and Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 Table 37 - Fields and Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 Table 38 - Fields and Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 Table 39 - Fields and Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 Table 40 - Fields and Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 Table 42 - Fields and Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 Table 41 - Fields and Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 Table 43 - Fields and Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 Table 44 - Fields and Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 Table 45 - Fields and Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 Table 46 - Fields and Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 Table 47 - Fields and Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 Table 48 - Clock Divisor X and Y . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 Table 49 - Clock Divisor Z . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Zarlink Semiconductor Inc.
xi
MT92210 List of Tables
Data Sheet
Table 50 - Fields and Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 Table 51 - t5 Write Access Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .171 Table 52 - t7 Read Access Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .172 Table 53 - Fields and Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 Table 54 - Fields and Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 Table 55 - Fields and Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
xii
Zarlink Semiconductor Inc.
Data Sheet
1.0 Features
The MT92210 device supports the following features:
MT92210
1.1
* * * * * * * *
General Features
Up to 1023 full-duplex PCM or ADPCM voice channels over IP/UDP/RTP connections Up to 4096 HDLC channels carrying application data (UDP payload) converted to IP/UDP connections Simultaneous support of PCM, ADPCM and HDLC connections 16-bit Intel/Motorola CPU Interface Fully H.110 compliant TDM interface Network Interface A: UTOPIA Level 1/2, POS-PHY Level 2 or MII Network Interface B: UTOPIA Level 1 Full chip capacity can be achieved with two 18 bit data bus ZBT SSRAM, each ranging in size from 128K to 1M bytes; one 36 bit data bus ZBT SSRAM, ranging in size from 128K to 1M bytes; and two 16 bit data bus SDRAM, each ranging in size from 8M to 16M bytes
1.2
* * * * * * * * * * *
Data Formats
Simultaneous support of IP version 4 and 6 Chip packages voice in RTP, UDP, and IP to support RFC791, RFC2460, RFC768, and RFC1889 IP packets can be sent over 3 different types of physical links (Ethernet, ATM, Packet over SONET) RTP packaging is optional per connection HDLC mini-packets are encapsulated in IP and UDP (RTP packaging performed by external agent) IP/UDP layers are optional and can be eliminated to reduce overhead (i.e., null encapsulation) in either ATM AAL5 or Ethernet (using custom EtherType) IP over AAL5 can be performed using Classical IP over ATM with SNAP/LLC headers or Ethernet LAN Emulation (LANE) v1 or v2 Support of MPLS. On reception, MPLS label can be used to establish data format following it, as well as logical subnet number and quality of service. MPLS multicast can be treated as unicast or routed to software Support of MPOA. On reception, MPOA tag can be used to establish data format following it, as well as logical subnet number and quality of service Logical subnet number can be established using ATM header, MPLS flow header, MPOA tag or ELAN-ID in LANE v2 header Quality of service can be determined using ATM header, Ethernet user priority or IP Type Of Service (TOS)
1.3
* * * * * * * * * * * * * * *
Voice Treatment Functions
Up to 1023 PCM/ADPCM channels Support for up to 4096 HDLC channels distributed over 512 streams and 2046 time slots Up to 255 PCM/ADPCM channels per connection HDLC packets contain application data (UDP payload) converted to IP/UDP datagram Packets sizes up to 1500 bytes for IP/UDP Support of up to 1500 TDM samples of data per packet Jitter Absorption Buffer size up to 4096 bytes allowing absorption of up to 256 ms of PDV Injection of CPU-generated RTP packets Reception of CPU-destined RTP packets in buffers of up to 64K bytes Packet Delay Variation monitoring to diagnose and reduce delay Packet loss & misinsertion compensation for PCM and ADPCM packets Network jitter monitoring allows support of RTCP for PCM, ADPCM, HDLC and CPU connections Policing on HDLC channels and CPU channels protects against misbehaving connections PCM, ADPCM, HDLC and CPU mini-packets can all be transported on the same connection with chip's RTP engine to guarantee consistency among the packets In the disassembly module, synchronization deltas allow multiple independent connections to be
Zarlink Semiconductor Inc.
13
MT92210
Data Sheet
synchronized end-to-end, allowing, for example, transparent transport of a DS3 over many IP connections
1.4
* * * * * * * * * * * * *
Network Functions
IP packet identification can be performed using any combination of IP source address, IP destination address, UDP source port, UDP destination port and RTP Synchronization Source Identifier and are programmable on a per-connection basis Non-voice packets can be injected and received via the CPU Interface Non-voice packets can be injected and received via the secondary UTOPIA port The MT92210 can be daisy-chained to other UTOPIA devices to increase capacity Off-the-shelf AAL5 SAR can be used to terminate data connections on a PCI bus Support of 16 different look-up profiles, each one of which can use different fields from the packet headers Look-up can be performed on a priority basis: for example, a packet can be looked-up using IP, UDP and RTP headers, then the look-up result can request a second lookup using only IP and UDP headers Binary tree of up to 128K nodes is used to route packets using packet identification key Dynamically balanced tree system ensures optimal performance IP, UDP and RTP header verification is performed Multihoming is supported with any number of local IP addresses Payload Type & Marker bit routing allows different compression formats as well as signaling packets to be transported on the same connection MPLS labels, MPOA tags and ELAN ID can be looked-up in binary tree to establish data format that will follow them, logical subnet number and quality of service
1.5
* * * * * * *
Silence Suppression and Padding
Proprietary Adaptive Silence Suppression Supported in both PCM and ADPCM formats Built-in detection of energy level Padding with matched-energy comfort noise 64 tone buffers used to generate tones (1 byte to 64Kb each) 32 large comfort noise buffers (16Kb to 64Kb) Suppression indication can be generated by chip or fed externally to synchronize with off-chip compression CODEC
1.6
* * * * * * * * *
H.110 Interface
Fully H.110 compatible H.110 Master and Slave capability Support of message channel Low Latency Loop-back (H.110 to H.110) of 128 channels (delay <= 375 us) Redundant Adaptive Clock Recovery Circuit Support of 2/4/8 MHz bus speed in groups of 4 streams (8 separate groups) Generation of H.110 compatibility signals Dual ct_netref signals Programmable fsync and TDM clocks for compatibility with other TDM buses
1.7
* * * * *
TDM data formats
Support of plain PCM in u-law and A-law Translation between u-law and A-law on a per connection basis Support of ADPCM at 40, 32, 24 or 16 kbps Dual time-slot mode allows dynamic, error-free switching between PCM and ADPCM formats with silence suppression Support of HDLC encapsulated mini-packets with asynchronous timing
14
Zarlink Semiconductor Inc.
Data Sheet
* * * *
MT92210
Support of HDLC streams ranging from 1 to 2046 time slots Support of HDLC packets with optional Address byte or word, optional Control byte and optional 16-bit CCITT-CRC Routing of HDLC streams according to HDLC address byte, with up to 512 channels per stream Support of HDLC packets up to 1500 bytes in length
1.8
* * * * * * * *
Link Interface
Ethernet support for MII interface Support for Ethernet MIB ATM using twin UTOPIA interfaces allow secondary data SAR to be daisy-chained with device for data connections Packet over SONET support for 16-bit POS-PHY bus allowing interoperation with PHY at speeds up to 155 Mbps Support for packets of up to 1500 bytes (plus MAC header) in Ethernet and up to 65535 bytes in ATM and Packet Over SONET Secondary UTOPIA port can be used in all modes allowing the same data support architecture to be used independently of the link layer with minimal changes Transmission of voice to secondary port allows H.110/PCM bridging when coupled with AAL5 SAR Pin-out allows designs that support Ethernet, ATM and Packet over SONET with only software configuration deciding on the link layer used
Zarlink Semiconductor Inc.
15
MT92210
Data Sheet
16
Zarlink Semiconductor Inc.
Data Sheet
2.0 CPU interface
MT92210
The CPU module serves as the main external interface of the MT92210 device. Through the CPU interface, external agents can program the MT92210 registers, and read or write to the internal or external memories. The interface is programmable to allow interaction with various types of external agents.
2.1
* * * *
CPU Interface Description
Direct Access Select (DAS) as the MSB bit concatenated with a 15-bit address bus 16-bit data bus 2 interrupt signals associated control signals.
The CPU interface is comprised of:
The CPU interface can be configured to operate in either Intel or Motorola mode, The MT92210 supports both 8-bit or 16-bit data bus and multiplexed or non-multiplexed address/data pins. Internally, a subset of registers -- CPU Interface Registers (000h to 00Ah), can be accessed with very low latency. These registers contain address indirection and data indirection bits. The controlling CPU can choose to launch an indirect access through these registers. Indirect reads will complete in due time when the data is available, while indirect writes are performed almost instantaneously. Direct accesses to the device can also be made. In these cases, accesses may take longer to complete. Any time a direct access is done, the CPU interface will delay the access using the cpu_rdy_ndtack pin until the access has completed internally. Note that direct writes are likely to complete very quickly as long as the write cache is not full.
2.2
CPU Interrupts
The CPU interface provides a programmable global interrupt capability. The interrupt signal are `interrupt1'and `interrupt2', pins Y5 and W4 respectively. Both interrupts have programmability to select their active polarity (open-collector drive) via registers `interrupt1_conf'and `interrupt2_conf', addresses 214h and 216h respectively. Interrupt1 provides the capability to program a minimum acceptable period between interrupts. The period is programmed in us units via the `interrupt1_conf' register. This provides a `frequency interrupt controller' facility and mask the assertion of further interrupts until the specified period of time has elapsed. The mask period will start when the interrupt1_treated[15] bit in the register `interrupt_treated' (address 212h) is set. When Interrupt2 is enabled it is always activated when an interrupt condition occurs. The operation of the CPU interrupt network is common for all modules. When an interrupt is asserted, an interrupt flag is set to identify the module where the interrupt was generated. On completion of the ISR the interrupt must be cleared as the interrupt will remain asserted until it is de-asserted by the user. All Interrupt Enable Registers have a mirror Status Register. Hence, the bit positioning of the interrupt enables and the corresponding status bits are identical. Interrupt pins are always tri-stated when inactive.
2.2.1
Example Interrupt Flow
Upon the initialization of the Globe Interrupt pins the following methodology is adopted to identify the source of the interrupt. For this example Interrupt2 is employed and the CPU module will be the source of the interruption.
2.2.1.1 Interrupt Initialization
Set interrupt polarity, register interrupt2_conf[15:14], address 216h. Enable Inetrrupt2 for the CPU module by setting bit 0 in inetrrupt2_enble register (21Ch). The MT92210 will generate an interrupt on interrupt2 pin according to the modules enabled in inetrrupt2_enable.
Zarlink Semiconductor Inc.
17
MT92210
2.2.1.2 Interrupt Servicing
When interrupt2 is asserted (`inetrrupt2' pin):
Data Sheet
1. Read the interrupt flags to ascertain the module raising the interrupt. The CPU module interrupt flag is located in register inetrrupt_flags(210h), this bit is named cpureg_interrupt_active. 2. If the cpureg_interrupt_active bit is set, check the source of the CPU interrupt by reading the `status0' register at 102h, either internal_read_timeout_sar, and/or inmo_read_done, and/or interrnal_read_timeout_net 3. To de-assert the interrupt the user must write 1 to corresponding bit in register 102h, ether internal_read_timeout_sar, and/or inmo_read_done, and/or internal_read_timeout_net. Only then will the interrupt be de-asserted.
b 15 b14 b13 b12 b11 b10 b9 b8 b7 b6 b5 b4 b3 b2 b1 b0
Status Bits internal interrupt
AND
OR
Interrupt Enable Bits Global Service Register (0210h)
Interrupt1 Enable (0218h)
AND
AND
Interrupt2 Enable (021Ch)
OR
OR
Interrupt Frequency Controler
interrupt2_active_level
interrupt2
interrupt1_active_level
interrupt1
Figure 2 - Internal Interrupt Network
18
Zarlink Semiconductor Inc.
Data Sheet
2.3 Intel/Motorola Interface
MT92210
The MT92210 CPU interface supports both Intel and Motorola modes, in both 8-bit or 16-bit data bus and multiplexed or non-multiplexed address/data pins. The MT92210 supports 128 Megabytes of addressable space, therefore extended addressing is necessary. The CPU interface directly addresses four control words, delegated for indirection accessing. All of the register spaces in this section provide extremely fast CPU access times. 000h 004h 008h 00Ah Control Register Read/Write Data Register Address High Register Address Low Register Table 1 - Indirect Access Register
CPU_MODE [3:0] 0000 0001 0010 0011
INTERFACE TYPE Intel, 16 bit data bus, non-multiplexed Intel, 16 bit data bus, multiplexed. Intel, 8 data bus, non-multiplexed Intel, 8 data bus, multiplexed Motorola, 16 bit data bus, non-multiplexed Motorola, 16 bit data bus, multiplexed Motorola, 8 bit data bus, non-multiplexed Motorola, 8 bit data bus, multiplexed Reserved
ALEa cpu_ale cpu_ale cpu_ale cpu_ale
ADDRESS PINb cpu_a[14:0] (word address) cpu_d[15:1] (word address) cpu_a[14:0] (byte address) cpu_a[14:8] & cpu_d[7:0] (byte address) cpu_d[14:0] (word address) cpu_a[15:1] (word address) cpu_a[14:0] (byte address) cpu_a[14:8] & cpu_d[7:0] (byte address)
DATA PIN cpu_d[15:0] cpu_d[15:0] cpu_d[7:0] cpu_d[7:0]
DIRECT_ ACCESS cpu_a_das cpu_a_das cpu_a_das cpu_a_das
0100 0101 0110 0111
cpu_ale cpu_ale cpu_ale cpu_ale
cpu_d[15:0] cpu_d[15:0] cpu_d[7:0] cpu_d[7:0]
cpu_a_das cpu_a_das cpu_a_das cpu_a_das
1xxx
Table 2 - CPU Interface Mode Selection
a. The cpu_ale pin is interpreted in all modes. However, it is not necessary in the non-multiplexed modes and can be tied to VCC. b. The address placed on the cpu_a[14:0] pin is a word address in 16-bit mode and a byte address in 8-bit mode. The address, when placed on the cpu_d pins, is always a byte address.
Zarlink Semiconductor Inc.
19
MT92210
Data Sheet
Field read_burst_length
Bit 6:0
Type RW
Reset 01h
Description Number of words to prefetch when any read is executed. 00h = 128; 01h= 1; 02h = 2, etc. The higher this number, the longer the first read in a sequential series of reads will take; all successive accesses will be very quick and the overall read performance will be much better. This field should be set to 1 for individual (non-sequential) reads. Any read burst that crosses a 256 byte boundary will be broken up into two bursts. Set by software when an extended access to the device must be started. Cleared by hardware when the access is completed. Used for extended indirect accesses only. Extended address bits 3:1. extended_a[32:0] points to bytes. Used for extended indirect accesses only. Active high write enables. "00" = read access (indirect only); "01" = write to lower byte; "10"=write to upper byte; "11"=write to entire word. Used both in extended indirect and extended direct write accesses. For all extended direct read accesses, this field has no effect. For all byte wide extended direct accesses, this field has no effect. Parity bits used for both reads and writes. Used both in extended indirect and extended direct accesses.
Reserved access_req
7 8
RO PC
0 0
extended_a[3:1] write_enable
11:9 13:12
RW RW
000 00
extended_parity
15:14
RW
00
Table 3 - Control Register (000h)
Field extended_data
Bit
Type Reset
Description
15:0 RW
0000h The 16 bits of data used in an extended indirect access to the chip. For all extended direct accesses, this field is not used. During write accesses, the write data is written here by the external CPU. During read accesses, read data returns here to be read. Table 4 - Read/Write Data Register (004h)
Field extended_a[32:20] Reserved
Bit 12:0 15:13
Type RW RO
Reset 0000h 000
Description Extended address bits 32:20. extended_a[32:0] points to bytes. Used both for extended indirect and extended direct accesses.
Table 5 - Address High Register (008h)
20
Zarlink Semiconductor Inc.
Data Sheet
Field extended_a[19:4] Bit 15:0 Type RW Reset 0000h Description
MT92210
Extended address bits 19:4. extended_a[32:0] points to bytes. Some bits in this register are not used in direct accesses. When operating the CPU interface with a 16 bit data bus, only bits 19:16 are used. When operating the CPU interface with an 8-bit data bus, only bits 19:15 are used.
Table 6 - Address Low Register (00Ah)
2.3.1
Extended Indirect Access Procedures
Extended Indirect Accessing solely employees the registers 000h to 00Ah to access the 128 Megabytes of addressable memory space. The access address is written to registers 000h, 008h, and 00Ah. The MT92210 will read/write to that address and fetch /place the data value from/to register 004h. For all extended indirect accesses the cpu_a_das pin will be held low.
2.3.1.1 Extended Indirect Writes
1. Write the upper address, extended_a[32:20], to register 008h. This may not be required if previous value holds true. 2. Write the lower address, extended_a [19:4], to register 00Ah. This may not be required if previous value holds true. 3. Write the write data, extended_data[15,0], to register 004h.This may not be required if previous value holds true. 4. Write write_enable, extended_parity, access_req='1' and extended_a [3:1] in a single access to register 000h. 5. Read the access_req bit located in the Control Register[8] to determine when the write cycle has completed. The software will set access_req[8] in register 000h. The hardware will reset the bit when the data write cycle has completed. Therefore, this bit can be polled to determine when the data write cycle has completed.
2.3.1.2 Extended Indirect Reads
1. Write the upper address, extended_a[32:20], to register 008h.This may not be required if previous value holds true. 2. Write the lower address, extended_a [19:4], to register 00Ah. This may not be required if previous value holds true. 3. Write write_enable="00", access_req='1' and extended_a [3:1] in a single access to register 000h. 4. Wait until access_req is cleared, then read data from the data field extended_data[15,0], register 004h. Optional parity check may be ascertained by performing a read on the extended_parity[15,14], register 000h. The software will set access_req[8] in register 000h and then the hardware will reset it when the data is ready to be read from register 004h.
2.3.2
Extended Direct Access Procedures
Extended Direct Accessing employs the high and low address registers to perform page addressing. The address within the page is provided directly by the CPU address bus. Similarly, the data is fetched/placed directly on the CPU data bus. The access address is written to registers 008h and 00Ah. This will perform only the page addressing. Upon assertion of the address within the page, the MT92210 will read/write the data with respect to that address. The
Zarlink Semiconductor Inc. 21
MT92210
Data Sheet
cpu_a_das pin is set when the data read/write occurs. When operating the CPU interface in direct mode with a 16-bit data bus, extended_a[19:16], are employed for the lower address word register 00Ah. However, when operating the CPU interface in direct mode with an 8-bit data bus, bits [19:15] are used for the lower address word.
2.3.2.1 Extended Direct Writes
1. Write the upper address, extended_a[32:20], to register 008h. This may not be required if previous value holds true. 2. Write the lower address, extended_a [19:16] or [19:15] to register 00Ah. The remaining bits [15:4] or [14:4] are ignored. This may not be required if previous value holds true. 3. Write write_enable[13:12] (This may not be required if previous value holds true) and extended_parity[15:14]. The extended parity write is optional. 4. Write data value to the address within the corresponding memory page with the cpu_a_das pin set.
2.3.2.2 Extended direct reads
1. Write the upper address, extended_a[32:20], to register 008h. This may not be required if previous value holds true. 2. Write the lower address, extended_a [19:16] or [19:15] to register 00Ah. The remaining bits [15:4] or [14:4] are ignored. This may not be required if previous value holds true. 3. Assert the lower address within the memory page and fetch the read data with cpu_a_das set. 4. Read the extended_parity field (optional), extended_parity[15:14], register 000h.
2.4
MT92210 Reset Procedure
The reset procedure for the MT92210 requires several steps, mostly due to the fact that there are several levels of hardware and software resets in the chip. All register accesses in the reset procedure maybe performed in either Direct or Indirect mode. The procedure to configure the chip is as follows: 1. Assert the nreset pin for at least one 1 ms. 2. De-assert the nreset pin. 3. Clear nreset bit in Register 100h, set Bit 9 (mem_oe), Bit 10 (ethernet_enable, if necessary), Bit 13 (low_latency_cpu_accesses) in Register 100h. 4. Configure upclk frequency in Register 10Ah. 5. Configure the fast_clock PLLs in Register 110h, 170h, 172h. 6. Configure H.110 PLL in Register 174h. 7. Set proper divisors in Register 164h, 166h. 8. Reset Bit 9 (mem_oe) in Register 100h. 9. Set Bit 0 (nreset_registers) in CPU Register 100h. 10. Set active levels for interrupt pins in the Main Registers (214h, 216h). 11. Configure external memories in the Main Registers (230h, 232h, 234h, 236h, 240h). 12. Set Bit 1 (nreset_chip) in CPU Register 100h. 13. Configure all the other registers. 14. Set Bit 2 (nreset_network) in CPU Register 100h.
22
Zarlink Semiconductor Inc.
Data Sheet
3.0 Network Interface
MT92210
The objective of the MT92210 device is to transport voice information encapsulated in IP packets over network connections. Therefore, to allow maximum flexibility, it can support 3 different types of link interfaces: Ethernet, UTOPIA and Packet over SONET. The network module of the chip is responsible for the identification and routing of packets, deciding which packets should be kept and treated as voice, which should be routed to the data packet buffer and which should be discarded. The network module accepts packets that are generated by the Packet Assembly module, as well as packets received from either of the two RX link ports. In the TX direction, it can send packets to the Packet Disassembly module, as well as to any of 4 TX link buffers: TX link A High-Priority, TX link A Low-Priority, TX link B High-Priority and TX link B Low-Priority. It can also receive cells from its twin UTOPIA ports or from the TX CPU cell queue and can route them to the RX CPU cell buffer, or one of 4 TX link A cell queues (in priority) or one of 2 cell queues going to TX link B. The following figure gives an overview of the data path in the network module, including all the queues that are used to buffer the data along the way:
Network Interface Buffering
Packet Reassembly Buffer RX Link B Cell FIFO 128 x 32 ATM Based Look-up Engine UTOPIA RX B Input FIFO 128 x 16 rxb_clk Clock Net RXB UTOPIA
RXCPU Agent Packet Disassembly Data FIFO 512 x 32
Network CPU Packet Buffer Packet Identifier Packet Identification Buffer
RX UTOPIA
S Packet Reassembly
Disassembly Module
Disassembly Disassembly Copying Buffer Process
RX Link A Cell FIFO 128 x 32 TX Link B Raw Cell Buffer 0 TX Link B HP Packet Buffer TX Link B LP Packet Buffer TX Link B Raw Cell Buffer 1 TX Link A Raw Cell Buffer 0 TX Link A HP Packet Buffer
UTOPIA RX A Input FIFO 128 x 16
RX UTOPIA
RXA UTOPIA
Packet to AAL5 Cells
HP
RXCPU Agent
RX CPU Raw Cell Buffer
Ethernet/POS RX Packet FIFO 128 x 36
RX Ethernet RX POSPHY
RXA MII RXA POS-PHY
rxa_clk or etha_rx_clk Clock Net TX Link B Copy txb_clk Clock Net
mem_clk_sar_i Clock Net
mem_clk_net_i Clock Net Packet Assembly Data FIFO 512 x 32 Assembly Copying Process
Assembly Module
LP
S
TX Link B Cell FIFO 128 x 32
TXB TX UTOPIA UTOPIA
TXCPU Agent
HP
Bufferless Process Buffer in Internal Memory Payload and Descriptor in SSRAM C Payload in SDRAM C, Descriptor in SSRAM C S Traffic Smoothing Processes (single leaky bucket) Clock domain crossings
TX Link A Cell FIFO 128 x 32
AAL5 Cells to Packet
TXA TX UTOPIA UTOPIA TX Link A Packet/Cell FIFO 128 x 36
TX Link A Raw Cell Buffer 1 TX Link A Raw Cell Buffer 2 TX Link A LP Packet Buffer TX Link A Raw Cell Buffer 3
TX TXA MII Ethernet TXA TX POS- POS-PHY PHY txa_clk or etha_tx_clk Clock Net
TX Link A Copy
Note: Only one type for port A is supported at once (UTOPIA, Ethernet or POS-PHY)
LP
Figure 3 - Network Interface Buffering
The module uses an external 32-bit SDRAM to buffer all the packets in transit and applies a linked list technique to allocate the blocks of memory in the SDRAM. Each packet, as it enters the module, is broken down into 48-byte payload blocks. These blocks are stored one at a time in SDRAM. A 19-bit link pointer links together the blocks that make up the packet. A link value of 00000h indicates that this block is the last one in the packet. Each block
Zarlink Semiconductor Inc.
23
MT92210
Data Sheet
occupies 64 bytes of SDRAM. The following figure 4 illustrates the format of blocks as they are kept in external SDRAM.
Packet Block Memory
+0 +40 +80 +C0 +100 +140 +180
Figure 4 - Packet Block Memory and Format
b31 b30 b29 b28 b27 b26 b25 b24 b23 b22 b21 b20 b19 b18 b17 b16 b15 b14 b13 b12 b11 b10 b9 b8 b7 b6 b5 b4 b3 b2 b1 b0 +0 +4 +8 +C +10 +14 +18 +1C +20 +24 +28 +2C +30 +34 +38 +3C Payload Payload Payload Payload Payload Payload Payload Payload Payload Payload Payload Payload Payload Payload Payload Payload Payload Payload Payload Payload Payload Payload Payload Payload Multicast Sum Payload Payload Payload Payload Payload Payload Payload Payload Payload Payload Payload Payload Forward Link Handle [24:6] Payload Payload Payload Payload Payload Payload Payload Payload Payload Payload Payload Payload
Figure 5 - Packet Block Format
24
Zarlink Semiconductor Inc.
Data Sheet
Field Payload Forward Link Handle Multicast Sum Description Packet payload. 48 bytes per block. Link to next block of packet. All zeros is invalid link (indicating end of packet). Used in TX. When packet is queued in multiple TX queues this is decremented each time the packet is sent and the TX queue that decrements it to 0 frees the cell memory. Table 7 - Packet Block Format Table
MT92210
Packets are managed in 7 queues. Each queue corresponds to a possible destination of a packet within the module. In addition to the 4 queues containing packets for the 2 TX link outputs, there are also queues for packets going to the Disassembly module, the RX CPU FIFO in external memory and the Packet Identifier module. Each of these queues can be configured independently as to a maximum number of blocks it may contain This prevents a single overflowing port to grab the entire SDRAM and rob properly functioning ports of the memory they need to operate. The CPU agent can also seize blocks from the linked list to write its packets destined to the CPU. The CPU must free those blocks once it has read them. In addition to the block queues, there are also 7 handle queues, each handle queue being associated to the block queues. The handle queues contain the handles identifying the packets contained within the block queue. These handles detail all the characteristics of the packets and are passed between agents until they reach their final destination. Each handle queue can be programmed to a 2n size. Note that while handles may be copied to a new handle queues (especially after passing through the packet identification section), the blocks that contain the packet itself are never moved. Each time a packet handle is added to a handle queue, the number of blocks it occupies is added to the block fill of the queue. Should the packet cause either the block fill or the handle fill to exceed their maximum values, the packet will be discarded and a per-queue status bit will be set in registers, indicating the error that has occurred. Note that the chip performs its own garbage collection, so no blocks in the linked list are ever left floating because the packet to which they were associated was lost. The network interface also supports multicast functionality: a single packet can be sent to multiple destinations simultaneously. A notable exception is that if a packet is being sent to the packet identifier, it cannot be sent anywhere else. A module called the packet handler manages all of these queues using a small internal memory shown in the next figure.
Zarlink Semiconductor Inc.
25
MT92210
Handle Queue Descriptors in Packet Handler Memory 4000E00h in internal memory +0 +10 +20 +30 +40 +50 +60 +70 Identification Buffer Network CPU Packet Buffer Disassembly Buffer TX Link B HP TX Link A HP TX Link A LP TX Link B LP Reserved
Data Sheet
Handle Queue Descriptor b31 b30 b29 b28 b27 b26 b25 b24 b23 b22 b21 b20 b19 b18 b17 b16 b15 b14 b13 b12 b11 b10 b9 +0 +4 +8 +C Blocks in Queue [18:0] Handle Read Pointer [14:0] Service Block Fill [18:2] Service Handle Fill [13:0] b8 b7 b6 b5 b4 b3 b2 b1 b0
Handle Queue Base Address & Size [20:11] Handle Write Pointer [14:0] Max Block Fill [18:6] Max Monitored Block Fill [18:3]
Figure 6 - Packet Handler Memory
Field Blocks in Queue Handle Queue Base Address & Size
Description Total number of blocks currently contained in queue. Indicates the base address of the handle queue as well as its size. The minimum queue size is 2K bytes, which is 128 handles. The maximum size is 256K bytes, which is 16K handles. The size is indicated by the lowest `1' in the field: for instance, if the field were xxxxxxxxxx1, this would represent a 2K byte buffer with a base address whose high bits are xxxxxxxxxx. If the field were xxxxxx10000, this would represent a 32K byte buffer with a base address whose high bits are xxxxxx. Pointer within the handle queue indicating the most recently read handle. Pointer within the handle queue indicating the most recently written handle. If the Blocks in Queue is less than or equal to this value, a service bit in registers can be set, indicating that the queue has gone below a certain fill. Both this and the handle fill must be valid for the service bit to be set. If the difference between Handle Write Pointer and Handle Read Pointer is less than or equal to this value, a service bit in registers can be set. Both this and the block fill must be valid for the service bit to be set. Indicates how many blocks, at most, the cache may contain before it overflows. This excludes the packet at the head of the queue, because it has been cached and will be treated shortly. Table 8 - Handle Queue Descriptor
Handle Read Pointer Handle Write Pointer Service Block Fill
Service Handle Fill
Max Block Fill
26
Zarlink Semiconductor Inc.
Data Sheet
MT92210
Handle queues are stored in SSRAM C. Each handle occupies a block of 16 bytes. Handle format is shown in Figure 7.
HQB
Handle Queue (FIFO)
+0 +10 +20 +30 +40 +50 +60 HWP HRP
HQB: Handle Queue Base address HRP: Handle Read Pointer HWP: Handle Write Pointer
Figure 7 - Handle Queue and Handle Format
Basic Handle Format
b31b30b29b28b27b26b25b24b23b22b21b20b19b18b17b16b15 b14b13b12b11b10 b9 b8 b7 b6 b5 b4 b3 b2 b1 b0 +0 +4 +8 +C RTD: RouTing Destination; bit to indicate next destination "xxxxxxxx1" = TX Link A Raw Cell Buffer 0 "xxxxxxx1x" = TX Link A Raw Cell Buffer 1 "xxxxxx1xx" = TX Link A Raw Cell Buffer 2 "xxxxx1xxx" = TX Link A Raw Cell Buffer 3 "xxxx1xxxx" = TX Link B Raw Cell Buffer 0 "xxx1xxxxx" = TX Link B Raw Cell Buffer 1 "xx1xxxxxx" = RX CPU Raw Cell Buffer "x1xxxxxxx" = AAL2 Raw Cell Buffer (not used for OAM packets) "100000000" = AAL5 VC (not used for OAM packets) SOP: Start Of Packet Handle is the index of the first block in Packet Block Memory BIP: Blocks In Packet is the number of blocks used to store the complete packet EOP: End Of Packet Handle is the index of the last block in Packet Block Pool TPL: Total Packet Length the total length of the packet in octets (max 65 535) is RTD Blocks in Packet[10:0] SOP Handle[18:0] EOP Handle[18:0] Total Packet Length[15:0]
Figure 8 - Basic Handle Format RX packets received from the packet assembly module are contained in a 2K byte internal memory. Once the full packet has been received, it is transferred to the SDRAM in block form. This internal buffer is large enough to contain an entire packet of up to 1500 bytes in length (+ link overhead). In addition to the packet memory, a small (128 bytes) handle memory contains the handles to these packets, indicating their length, base address and
Zarlink Semiconductor Inc.
27
MT92210
Data Sheet
destination. Packets from the packet assembly module can be routed to any one of the TX link buffers or to the packet identifier for internal loopback functionality. Packets going to the disassembly module use a similar scheme: a 2K-byte memory is used for the packets and a 128-byte memory for the handles. Near the TX link layer interface, the network module uses 512-byte buffers to transfer packets between the SDRAM and the link layer interfaces. There are 4 buffers used for this purpose: 1 destined to TX link A, 1 to TX link B, 1 from RX link A and 1 from RX link B. These buffers can be smaller because the system operates flawlessly even if the entire packet is not contained in the buffer at any one time. Cells contained in external memory are stored in the SSRAM and free cells are allocated as the various modules within the chip request them. The cells are also managed in a linked list, in the same way as the packet are. However, since each cell is individual (i.e. not part of a packet comprised of many blocks) they are only linked when they are free: when a cell is allocated and contains valid data, its link is not used. Whenever cells are allocated, the pointer to the cell is added to a cell queue, which contains all cells going to a given destination. The following figures indicate the format of raw cells in queues, depending on whether the cell is allocated or free:
b31 b30 b29 b28 b27 b26 b25 b24 b23 b22 b21 b20 b19 b18 b17 b16 b 15 b14 b13 b12 b11 b10 b9 +0 +4 +8 +C +10 +14 +18 +1C +20 +24 +28 +2C +30 +34 +38 +3C Multicast Sum Cell Header[31:0] Cell Payload Cell Payload Cell Payload Cell Payload Cell Payload Cell Payload Cell Payload Cell Payload Cell Payload Cell Payload Cell Payload Cell Payload PN
b8
b7
b6
b5
b4
b3
b2
b1
b0
AAL5 VC Number [15:0]
Figure 9 - Raw Cell Format (used cell) Field Multicast Sum AAL5 VC Number PN Description Used in TX. When Cell is queued in multiple TX queues this is decremented each time the cell is sent and the TX queue that decrements it to 0 frees the cell memory. This points to a Packet Reassembly structure. Port Number. Used in RX. Source port of this cell. Used to indicate, in the RX AAL0 FIFO, where cells originated. "00" = RX port A, "01" = RX port B; "11" = TX CPU. Table 9 - Fields and Description
28
Zarlink Semiconductor Inc.
Data Sheet
MT92210
b31 b30 b29 b28 b27 b26 b25 b24 b23 b22 b21 b20 b19 b18 b17 b16 b15 b14 b13 b12 b11 b10 b9 b8 b7 b6 b5 b4 b3 b2 b1 b0 +0 +4 +8 +C +10 +14 +18 +1C +20 +24 +28 +2C +30 +34 +38 +3C Cell Header[31:0] Cell Payload Cell Payload Cell Payload Cell Payload Cell Payload Cell Payload Cell Payload Cell Payload Cell Payload Cell Payload Cell Payload Cell Payload Link to Next Free Cell [20:6]
Figure 10 - Raw Cell Format (free cell)
Field Link to Next Free Cell
Description Points to the next free cell in SSRAM. Table 10 - Fields and Description
There are multiple cell queues in the chip: 4 going to TX A, 2 going to TX B, and 1 to the RX CPU. Each one of them keeps a list of cells pointed to in external memory. Each cell queue is of a programmable 2n size between 64 cells (4K bytes) and 8K cells (512K bytes). If a cell queue overflows, a status bit will be flagged in registers. As is the case with packets, a cell handler module manages the read and write pointers to the queues. However, instead of being contained in a small internal memory, all pointers and configuration of each cell queue is contained in registers. However, a small internal memory is used to prefetch pointer to cells destined to each queue to prevent starvation. The format of this memory is described in the following figure.
Zarlink Semiconductor Inc.
29
MT92210
Queues in Cell Handle Memory
Data Sheet
4002000h
+0
Reserved
+100
8 Read Pointer Queue (TX A Raw Cell Buffer 0) 8 Read Pointer Queue (TX A Raw Cell Buffer 1) 8 Read Pointer Queue (TX A Raw Cell Buffer 2) 8 Read Pointer Queue (TX A Raw Cell Buffer 3) 8 Read Pointer Queue (TX B Raw Cell Buffer 0) 8 Read Pointer Queue (TX B Raw Cell Buffer 1) 8 Read Pointer Queue (RX CPU Raw Cell Buffer) Reserved
+120
+140
+160
+180
+1A0
+1C0
+1E0
Format of 8 Read Pointer Queue b31 b30 b29 b28 b27 b26 b25 b24 b23 b22 b21 b20 b19 b18 b17 b16 b15 b14 b13 b12 b11 b10 b9 b8 b7 b6 b5 b4 b3 b2 b1 b0 +0 +4 +8 +C +10 +14 +18 +1C Read FIFO Cell Base Address [20:6] Read FIFO Cell Base Address [20:6] Read FIFO Cell Base Address [20:6] Read FIFO Cell Base Address [20:6] Read FIFO Cell Base Address [20:6] Read FIFO Cell Base Address [20:6] Read FIFO Cell Base Address [20:6] Read FIFO Cell Base Address [20:6]
Figure 11 - Cell Handler Memory
30
Zarlink Semiconductor Inc.
Data Sheet
4.0 Link Layers
MT92210
This chapter describes the link-layer interfaces, as well as the packet reassembly structure used to transport their data.
4.1
Interfaces
The MT92210 device can support 3 different types of primary link layers: Ethernet, which uses the MII bus to communicate with an Ethernet PHY, ATM AAL5, which uses the UTOPIA bus, and Packet over SONET, which uses a 16-bit POS-PHY bus to interface with a SONET PHY. Each of these modes has its own headers to identify IP packets over the link layer and the MT92210 is directly compatible to Physical Layer chips for each of the three interfaces. In addition to its primary network interface, the MT92210 supports a secondary UTOPIA port that can be used to connect a data SAR to the chip, or to daisy chain several MT92210 chips together. This secondary port is always a UTOPIA port, independently of the configuration of the primary port. The chip is capable of treating IP packets from both ports and can convert from one link layer to the other if need be.
4.2
Ethernet Interface
The MT92210, when configured to operate in Ethernet mode, can operate using 10 or 100 Mbps Ethernet in either full- or half-duplex mode. When transmitting Ethernet packets, the chip will transmit the preamble, the packet itself and the CRC-32 that it has calculated over the entire packet. The chip will abort its packet transfer in case of collisions and it will back-off for a random period of time as specified by the Ethernet standard. If a packet retransmission is attempted 16 consecutive times, the packet will be discarded and an error will be flagged to registers. When receiving Ethernet packets, the chip will verify the packet for the correct destination MAC address, the correct payload size, the correct CRC-32. When parsing the packet, the chip will accept destination MAC addresses that correspond to its own, as well as broadcast addresses; it can also be configured to accept all MAC addresses, as well as selecting canonical or non-canonical formats of MAC addresses. The length/type is checked and the packet is identified as IP/non-IP. The chip can also accept Ethernet headers that conform to the 802.1-p/Q specification. Packets received on the Ethernet interface can range in size between 64 bytes and 1500 bytes plus headers, in keeping with the Ethernet specification. Any larger or smaller packets will be discarded and an error bit will be flagged in registers. The reporting of these errors is necessary for the support of Ethernet MIB. All transmission and reception of data over Ethernet is done through the MII interface that communicates with an Ethernet PHY.
4.3
Packet over SONET Interface
When using Packet over SONET, the MT92210 interfaces with a SONET PHY that allows packets to be transferred over SONET using PPP. When using this mode, transmitted packets are given a 1 or 2 byte PPP header before being sent onto the link: this header indicates that the packet is IP. When receiving packets, some filtering is done: because PPP is, by definition, point-to-point, all packets received are indeed destined to the chip, but padding packets must be deleted and non-IP packets must be flagged as such before being sent to the usual look-up flow. The Packet over SONET interface uses a 16-bit POS-PHY bus used to communicate with SONET PHY. MT92210 doesn't implement address bus therefore multi-PHY configuration is not supported. The Packet over SONET interface can support packets ranging in size anywhere from 1 to 65535 bytes in length: any packet longer than 64K bytes will be discarded and an error will be flagged in registers. The chip will also discard any packets that are aborted by the PHY during transfer, as indicated by the rxa_err pin.
4.4
UTOPIA Interface
The MT92210 has a primary link layer port (Port A) that can be configured as Ethernet, ATM or Packet over SONET. In addition, it has a secondary port (Port B) that is always configured to operate as an ATM port. Port B can be used to interoperate with a secondary data SAR, or to daisy chain several MT92210 devices together onto a single network connection. By keeping the same secondary port configuration independently of the mode in which
Zarlink Semiconductor Inc.
31
MT92210
Data Sheet
the primary port operates, the MT92210 can interface with the same external SAR in all modes with minimal changes. Cells received on the secondary UTOPIA port, as well as any cells received on the primary port when it is configured to operate in ATM mode, navigate through the UTOPIA module to reach their final destination. To multiplex and de-multiplex traffic, the UTOPIA module uses input and output FIFO to contain cells. All cells sent to the module are written into 4-cell input FIFO, which not only buffers a small amount of data but also serves the synchronization needs of the various network clocks. These cells are then passed by a look-up engine whose job is determining the VC number, as well as whether they should be kept or discarded. Cells arriving from either of the UTOPIA ports need to be looked-up. To do so, 2 look-up tables are mapped in the external SSRAM. To point to an entry in the SSRAM, a combination of bits from the VPI and VCI is used. Each look-up table can contain up to 2^16 entries = 64K entries, so up to 16 bits of the header can be used for the address. Once the look-up engine has determined the VC number to which the cell is destined, it writes it to the appropriate output FIFO. The output FIFO are larger, since they are necessary to buffer the peaks that occur in traffic. The output FIFO are 8 cells deep. From these output FIFO, AAL5 cells are sent to the RX link agent for reassembly. On the input side (UTOPIA reception), the UTOPIA ports can be configured through registers to behave as PHY or ATM layers on the UTOPIA bus, depending on which chip is being interfaced with. In addition, each port has an individual enable bit which prevents all traffic from being received on that port. Each port detects the parity on the UTOPIA bus and any parity error will be reported to registers. Finally, null cells can also be enabled or disabled on a per-port basis and any cells containing null headers will be deleted if this feature is enabled. Null headers can be identified under either UNI or NNI conditions. On the output side (UTOPIA transmission), the ports can also be configured as PHY or ATM layers. The TX interfaces can also be configured to operate in multi-PHY mode, meaning that they will only drive the port's tx_d, tx_prty and tx_soc pins if this port has been selected to drive data onto the UTOPIA bus. Note that multi-PHY mode only applies when the port is configured to operate as a PHY layer. The Look-Up Table (LUT) of the UTOPIA is the central element to the module's behavior. It analyzes every cell received from one of the UTOPIA ports and determines where the cell goes. A cell coming from port A or B will first have its header compared with match and mask fields which indicate what are the acceptable header values coming from this port. The way the match and mask operate is that the mask indicates which bits of the header must be fixed and which may take on any value. For all bits whose mask value is '1' (fixed), the match indicates what this value must be. This method is applied bit-wise to the VPI and VCI portions of the header. Any cell not meeting these criteria will be routed according to the rx_normal_vc_dest or rx_oam_vc_dest bits contained in registers. These fields indicate, for cells whose header does not match, where they should be routed: once again, these fields support unicast, multicast or broadcast routing of cells. Depending on the OAM bit of the header, either rx_normal_vc_dest or rx_oam_vc_dest will be used, to allow management cells to be routed differently from data cells. The routing fields are different for each input port. However, if this validation procedure is passed, the look-up engine uses a certain number of bits from the VPI and VCI of the cell header to determine the look-up entry corresponding to the cell. The number of bits of VCI used is determined by the vci_n field, which is unique per port and can be configured from 0 to the full 16 bits of header: note that the bits used are always the lower bits of the VCI. The rest of the bits are taken from the low bits of the VPI, up to the full size of the look-up table (anywhere from 2^10 entries to 2^16 entries). These bits are then concatenated to form a look-up address offset, which is added to the look-up table's base address to form the absolute address of the look-up entry. The information at this address then reveals whether the cell will be kept and to which cell queue it belongs, as well as a VC number if it is AAL5. The routing can be performed differently for normal and OAM cells: in a typical application, OAM cells will be routed to one of the raw cell queues, while user cells will be sent to an AAL5 VC. The format of the look-up table entries is described below:
32
Zarlink Semiconductor Inc.
Data Sheet
+0 +4 LUT Entry 0 LUT Entry 1
MT92210
+(N-2)*4 +(N-1)*4
LUT Entry N-2 LUT Entry N-1
Figure 12 - UTOPIA Look Up Table
Indexing within the UTOPIA LUT is done using programmable VPI/VCI bits. See registers 420h to 42Ah and 440h to 44Ah. N is a 2^n number between 1024 and 65536. The base address starts on a boundary equal to the size of the LUT. The LUT is located in SSRAM C.
b31 b30 b29 b28 b27 b26 b25 b24 b23 b22 b21 b20 b19 b18 b17 b16 b15 b14 b13 b12 b11 b10 b9 b8 b7 b6 b5 b4 b3 b2 b1 b0 +0 Normal Cell Route OAM Cell Route AAL5 VC Struct Base [20:5]
Figure 13 - UTOPIA LUT Entry Format
:
Field Normal Cell Route
Description "xxxxxxxx1" = TX Link A Raw Cell Buffer 0; "xxxxxxx1x" = TX Link A Raw Cell Buffer 1; "xxxxxx1xx" = TX Link A Raw Cell Buffer 2; "xxxxx1xxx" = TX Link A Raw Cell Buffer 3; "xxxx1xxxx" = TX Link B Raw Cell Buffer 0; "xxx1xxxxx" = TX Link B Raw Cell Buffer 1; "xx1xxxxxx" = RX CPU Raw Cell Buffer; "x1xxxxxxx" = reserved; "100000000" = AAL5 VC; "xxxxxx1" = TX Link A Raw Cell Buffer 0; "xxxxx1x" = TX Link A Raw Cell Buffer 1; "xxxx1xx" = TX Link A Raw Cell Buffer 2; "xxx1xxx" = TX Link A Raw Cell Buffer 3; "xx1xxxx" = TX Link B Raw Cell Buffer 0; "x1xxxxx" = TX Link B Raw Cell Buffer 1; "1xxxxxx" = RX CPU Raw Cell Buffer; When a VC's Normal Cell Route indicates that its cell should be sent to the Packet Reassembly module (for AAL5 reassembly), this points to a Packet Reassembly structure. Table 11 - Fields and Description
OAM Cell Route
AAL5 VC Struct Base
Zarlink Semiconductor Inc.
33
MT92210
4.5 Packet Reassembly
Data Sheet
When communicating only IP packets, the MT92210 can use Ethernet, Packet over SONET or ATM as its primary network interface. The primary interface must be a Utopia bus to carry AAL0 cells, other ATM cells that can carry signaling, and packets broken down and carried over AAL5. Any packets transmitted or received over AAL5 on the link will be done so one cell at a time, contrarily to Ethernet and Packet over SONET, which both transfer and receive entire IP packets. On the transmission side, this is not a problem: each packet is broken down into as many AAL5 cells as necessary and the cells are then sent one at a time over UTOPIA. The reception side is a little trickier: as ATM cells are received, they must be targeted to a connection in order to determine if they are AAL5 carrying IP or another protocol, or "raw" cells which will be routed to another port or to software. To do so, the chip consults an ATM header look-up table. The look-up table is contained in external SSRAM and can use up to 16 header bits to determine the destination of the cell. The result of this look-up points to a destination field for non-OAM cells as well as one for OAM cells (note that OAM cells cannot be AAL5). The cells are then sent to their appropriate destinations. If the cells are AAL5, an AAL5 VC structure base number is also listed. The AAL5 reassembly structure contains all information about the current packet and the connection to which it belongs, such as the number of cells contained in the packet so far, and diagnostic information indicating how many bytes, cells and packets have been received on this connection since start-up. It also contains a Flow Table Pointer: this pointer uniquely identifies a Flow, which corresponds to a logical subnet number. The Flow Table Pointer can be modified later in the packet's life according to any MPOA tags, MPLS labels or ELAN-IDs it may contain. If none of these modifications have taken place, then the Flow Table Pointer corresponds directly to the VC number. When the last cell is received and the packet is reassembled successfully, the complete packet is checked for correct length and correct CRC: an error in either of these will cause it to be discarded. If the packet passes these tests, it will be sent to the packet identification queue, where it will be routed to its final destination. When the packet is ready to be treated, the look-up table will indicate whether it is a data packet, or it needs to be sent through the regular IP packet flow. It is to be noted that, to save overhead, some implementations eliminate IP/UDP headers to save bandwidth. Like all other network interfaces, AAL5 can also support voice packets both with and without RTP headers. If the IP/UDP packet routing is chosen and the IP header is present, the look-up proceeds using the IP and UDP headers (and possibly the RTP synchronization source) to identify the packet. However, if the IP and UDP headers are absent, the 24-bit Flow Table Pointer is added to the binary tree look-up key. Only the RTP SSRC can be used along the Flow Table Pointer in the search, as long as RTP is present in the packet. Otherwise, the packet will be looked-up using only the Flow Table Pointer. IP packets carried over AAL5 can be encapsulated using Classical IP over ATM or LANE version 1 or 2. Classical IP over ATM uses an 8-byte SNAP/LLC header at the beginning of the packet to identify the type of the packet (e.g. IP). Packets using LANE have an Ethernet-compatible header before the IP header, containing the Destination and Source MAC addresses corresponding to the packet, as well as an Ethernet Length/Type field that, in the same way as the SNAP/LLC type, identifies the protocol above it (IP or other). LANE v2 also uses LLC encapsulation and contains an ELAN-ID that may be used to resolve a logical subnet number. LANE headers may be compatible to Ethernet p/Q. The Destination MAC address in the LANE header will be checked in the same way as it would be in an Ethernet packet: the chip will accept MAC addresses corresponding to its own, as well as broadcast MAC addresses. MAC address checking can also be disabled and all packets will be accepted. When the primary network interface is configured as Ethernet or Packet over SONET, a single Reassembly structure is used and all packets are routed to this structure. Since Ethernet and Packet over SONET do not break down packets, interleave them, or carry several packets over different VC, the packets always arrive contiguously, thus not requiring more than 1 structure.
34
Zarlink Semiconductor Inc.
Data Sheet
VC Struct Base in LUT Register A20h
MT92210
Utopia Port
+0 +20 +40 +60 +80 +A0 +C0
Ethernet/POS port
Packet Reassembly Struct
AAL5 AAL2/AAL5 Reass. Struct AAL5 AAL2/AAL5 Reass. Struct AAL5 AAL2/AAL5 Reass. Struct AAL5 AAL2/AAL5 Reass. Struct AAL5 AAL2/AAL5 Reass. Struct AAL5 AAL2/AAL5 Reass. Struct AAL5 AAL2/AAL5 Reass. Struct
Figure 14 - Location of Reassembly Structures This is the format of the AAL5 Packet Reassembly Structure (also used for Ethernet and POS).
b31 b30 b29 b28 b27 b26 b25 b24 b23 b22 b21 b20 b19 b18 b17 b16 b15 b14 b13 b12 b11 b10 b9 b8 b7 b6 b5 b4 b3 b2 b1 b0 +0 CC +4 +8 +C +10 +14 +18 +1C Length Error Count [7:0] CRC Error Count [7:0] EPD Packet Cell Count [10:0] V 1st Header SIP AIP ER P CRC-32 Next Cell Handle [18:0] SOP Handle [18:0] Connection Packet Count Connection Cell Count [23:0] Connection Packet Byte Count Flow Table Pointer [26:3] Max Packet Size [15:0]
Figure 15 - Packet Reassembly Structure
Zarlink Semiconductor Inc.
35
MT92210
Field
CC V
Data Sheet
Description
CRC Check Enable. This should always be set to `1' if communicating with an AAL5 agent, and set to `0' if this structure is receiving from an Ethernet or POS agent. Valid bit. When `0', any cell arriving on this VC number will be discarded as if it never arrived. Caution: this bit can be cached by hardware, so when it is cleared, the rxaal5_empty_cache bit in registers must be set (it will be cleared by hardware when the cache is empty). "0000" = VC starting with the LLC Header; "0001" = VC starting with a PPP Header; "0010" = VC starting with an IP Header; "0011" = VC starting with an MPLS Unicast Header; "0100" = VC starting with an MPLS Multicast Header; "0101" = VC starting with an MPOA Tag; "0110" = VC starting with a LANE-Ethernet/802.3 Header; "0111" = VC starting with a UDP payload (with or without RTP); others = reserved. MPLS IP indicator. "11" = reserved; "10" = RTP/UDP payload; "01" = IP, "00" = must be looked-up. This value can be overridden later in the packet parsing process by a binary tree look-up using the MPLS label. Usually set to "00". MPOA IP indicator. "11" = RTP/UDP payload, "10" = IP, "01" = MPLS unicast, "00" = must be looked-up. This value can be overridden later in the packet parsing process by a binary tree look-up using the MPOA tag. Usually set to "00". ELAN Resolved. When `1', any ELAN-ID present is considered resolved, and will not have to be looked-up to generate a Flow Table Bit Pointer. Usually set to `0'. Priority of packet. `0' = LP; `1' = HP. Maximum packet size in bytes (inclusive), including link layer protocol headers and up. Minimal value 128, maximum value 65535. This number never includes the ATM header, but includes the PPP header in Packet over SONET, and includes the Ethernet header and a 2-byte LANE header in Ethernet. This number never includes the frame CRC. Calculated by hardware during packet reception. Used to compare with CRC inside the received packet. `0' = all is well; `1' = Early Packet Discard. In this case, the packet will be thrown out when the last cell is received. This can be set because the packet length exceeded the Max Packet Size. This bit is only used by hardware; set to `0' initially by software. Counter of the number of cells contained in the packet so far. Should be reset to 000h. This counter excludes the Next Cell Handle, since this handle has been seized for a cell that has not yet arrived. Pointer to the block that has been pre-allocated for storing the next cell payload when it is received.
1st Header
SIP
AIP
ER P Max Packet Size
CRC-32 EPD
Packet Cell Count Next Cell Handle
Table 12 - Fields and Description
36
Zarlink Semiconductor Inc.
Data Sheet
Field
SOP Handle Length Error Count
MT92210
Description
Pointer to the first block of the chain that contains the packet payload. Indicates the number of length errors that have been detected on this connection. Length errors are reported when the received AAL5 length is 0, when the AAL5 length is too large to fit in the number of cells received in this packet, when the packet length (either the explicit AAL5 length, or the implicit length in Ethernet or POS) is greater than Max Packet Size, and when the number of cells received in this packet is too large for the Max Packet Size (i.e. the total number of cells received contains 0x38 or more payload bytes than the Max Packet Size). Counts the total number of packets received on this VC to date. Counts the total number of CRC errors detected on this VC since initialization Counts the total number of cells received on this VC to date. Counts the total number of packets received on this VC since initialization
Connection Packet Count CRC Error Count Connection Cell Count Connection Packet Byte Count Flow Table Pointer[26:3]
This field represents the logical subnet number on which the packet is received. The logical subnet number is initially bound either to the link (in the case of Ethernet or POS) or to the VC on which the packet is carried (in the case of ATM). This field can be overridden later on by protocols that allow VCs to carry packets on multiple subnets, such as LANEv2 or MPOA. The Flow Table Pointer points to a single bit in SSRAM C.
Table 12 - Fields and Description
Zarlink Semiconductor Inc.
37
MT92210
Data Sheet
38
Zarlink Semiconductor Inc.
Data Sheet
5.0 RX/TX Data Flows
This chapter describes the data flows for all packets received and transmitted.
MT92210
5.1
RX Data Flow
This section resumes the typical propagation of voice data throughout the MT92210 in the receive direction, from the link to the H.110 bus. Packets arriving off the link are written into memories, either a cell input FIFO if the link is configured as a UTOPIA interface, or a packet input FIFO if the link is configured as an Ethernet or Packet over SONET interface. For the ports that are configured as UTOPIA, the cells then go through the UTOPIA look-up process, which indicates what their nature is, either raw cells going to a cell destination, or AAL5 cells to be reassembled into a packet. After they are looked-up, they are written into the RX link A or RX link B cell FIFO. If port A is configured as Ethernet or POS, its packets go through a packet to block conversion process, where they are broken down into 48-byte blocks. In addition, Ethernet headers are converted to LANEv1 headers, and POS is mapped as PPP over AAL5. The packets are then written into the RX link A cell FIFO. As of this point, all packets look identical within the chip, independently of the link interface. The cells are then read by the packet reassembly process and written into external SDRAM until the packet to which they belong is complete. Cells that are tagged as non-AAL5 pass by the packet reassembly process but are routed immediately to their own destination, which is already known because it was indicated in the UTOPIA look-up table. These cells may be sent back onto one of the TX links, or they may be routed directly to the CPU.
Zarlink Semiconductor Inc.
39
MT92210
Data Sheet
UTOPIA look-up: Searches for cells based on their VPI/VCI, establishes their destination, associates them to a Packet Reassembly Structure.
Packet to block conversion: Converts Ethernet or Packet over SONET packets into 48-byte cell blocks, padding at the end. Packet Reassembly: Accumulates the cells on many VCs, checks for AAL5 errors, flags completion of packets. Packet Reassembly Structure (1 per VC, 1 global in Ethernet/POS) NET1
AAL5 VC Struct Base
UTOPIA look-up table (1 per port) UTOPIA0
RX link B cell FIFO (global) Packet Reassembly port A = UTOPIA
UTOPIA RX B input FIFO (global) UTOPIA look-up UTOPIA RX A input FIFO (global)
From link B
RX link A cell FIFO (global)
From link A
Network Packet Buffer NET2-4 Legend:
port A = Ethernet/ POS
Packet to block conversion
Ethernet/POS RX packet FIFO (global)
Structure in Internal Memory Raw Cell Buffer RAWCELL0-1 Structure in SSRAM A Structure in SSRAM B Structure in SSRAM C Structure in SDRAM C
Data propagation Control propagation Data+Control propagation Structure Base Address or Index Chip Process Software Process
Figure 16 - Rx Flow 1
Cells of AAL5 VC will go to the packet reassembly process; when a packet completes in the packet reassembly process, its handle is sent to the packet identification buffer. The packet identifier parses through the packet, identifying various headers and extracting the identification key with which the packet will be searched for. The packet identifier also consults the Next Header memory and the Profile Memory to decide what to do if it encounters certain next header or option values. Once the packet parser has assembled all of the necessary headers, it consults the initial search structure to decide what to do with the packet. In the case of a voice packet, the structure should tell it to search in the binary tree using a specific profile. It then passes the packet to the identification key hashing process. This process performs CRC on the identification key and annexes the profile number to it to obtain a full 60-bit key, which is then used to search for the packet in the binary tree. When the correct node is found in the binary tree, that node points to a post-search confirmation structure. The headers contained in this structure are then compared to the headers used initially to form the packet's identification key. In addition, the flow table is searched to verify whether the destination IP address of the packet can be received on the current logical subnet. If both tests are passed, then the packet matches the post-search confirmation structure, which then indicates what its destination should be. If the packet does not match, then it keeps on being searched until it hits a post-search confirmation structure it matches with, or it hits the default structure for its profile that gives it a default destination.
40
Zarlink Semiconductor Inc.
Data Sheet
RX RTP Connection Structure Base Address First PostSearch Post-Search Confirmation IP Address Confirmation Structure Index Flow (points to an Structure (1 Address Binary Tree Table (1 entry in the per (global) ID6 per Flow Table) connection or logical header) ID2 subnet) Profile Default ID0 Post-Search Structure (1 per profile) ID2
MT92210
Profile Memory Entry (Hash Key Mask) (1 per Profile) ID1
Initial Default Post-Search Structure (1 per packet type) ID2
Next Header Memory (global) ID4
Profile Memory (Option + TOS) (global) ID1
Post-Search Process
Binary Tree Search
Identification Key CRC + hashing
Identification Key (preCRC)
Packet Parsing
Packet Identification Buffer Handles (global) NET6
If the post-search process decides to search for the packet in the binary tree using another profile
If the initial search was for an MPLS label, MPOA tag or ELAN ID, and the result is valid, then the packet will be parsed again, ignoring that header
RTP Data
Packet Parsing: Reads through the headers of the packet, finds protocol errors, extracts the headers that will be used to form the identification key based on the packet type. Identification Key CRC + hashing: Applies a mask to the identification key, then performs a CRC on it, and annexes the profile number to obtain a 60-bit key. Binary Tree Search: Searches for the identification key in the binary tree. If it succeeds, returns a pointer to a Post-Search Confirmation Structure. If it fails, the Profile Default Structure will be consulted. Post-Search Process: Compares the packet's headers to those in the post-search confirmation structure. Also checks if the packet passes the flow table look-up. If the packet fails, it will use the profile default structure to establish its destination. The destination may be back to the packet identifier (in the case of a header, i.e. MPLS, MPOA, ELAN-ID) or back to the Identification Key CRC + hashing process, if the established destination is to route using another profile.
Figure 17 - Rx Flow 2
The packet's destination may be one of the TX link packet buffers, the Network CPU packet buffer, or the packet disassembly module. If the packet's destination is the packet disassembly module, then the post-search structure will contain a pointer to a valid RX RTP Connection Structure. The packet is then written into the Packet Disassembly Memory and read on the other side by the packet disassembly module. The packet disassembly module reads the RX RTP Connection Structure, and based on the Marker bit and Payload type of the packet (or its UDP length, if it carries no RTP), it will search in the Payload Byte/Marker Bit table for the entry number that corresponds to the current packet. The entry number will point to 1 of 16 RX RTP channel structures, which may be xxPCM Channel Structures, HDLC Channel Structures, CPU Channel Structures or may indicate to delete the packet. An RX RTP xxPCM Channel Structure will contain pointers to one or many circular buffers in which its PCM data will be written, depending on how many bearers it carries. It will also contain a pointer to an RTP Common PDV Absorption Structure, which will be used to do de-jittering on the bearer's payload. Many xxPCM Channels can share the same Common PDV Absorption Structure, which allows them to be de-jittered in common and ensures that a slip on one will force a slip on all. If the selected channel structure is an RX HDLC Channel Structure, then it will contain a pointer to an RX HDLC Stream/Buffer Control Structure, which will itself point to a circular buffer. In HDLC, channels are policed independently, but are then merged into a common circular buffer for the entire stream. The RX HDLC Stream/Buffer Control Structure will contain the base address as well as the read and write pointers to this circular buffer. If the selected channel structure is an RX CPU Channel Structure, it will contain a pointer to an RX CPU Buffer Control Structure. Except for the fact that the CPU Channel Structure will not request HDLC framing to be
Zarlink Semiconductor Inc.
41
MT92210
Data Sheet
performed on the packet and that no HDLC address or control byte insertion will be done, it is otherwise identical to the RX HDLC Channel Structure.
RTP-only structures RX CPU Circular Buffer (1 per Buffer) RXCIRC2-3 RX CPU Buffer Control Table (1 per Buffer) RXCIRC1 RX HDLC Stream/Buffer Control Table (1 per Stream) RXCIRC0 RX RTP CPU Channel Structure (1 per channel) DISAS11 RX RTP HDLC Channel Structure (1 per channel) DISAS10
Payload Type/Marker Bit Table (1 per connection) PTM1
RX HDLC Circular Buffer (1 per Stream) RXCIRC5
RX RTP Connection Structure (1 per connection) DISAS8 RX RTP xxPCM Channel Structure (1 per channel) DISAS5 CN Packet Conversion Lookup Table (global) RXTDM3
Event Report Queue (global) RXQUEUE0-4
RX xxPCM Circular Buffer (1 per Bearer) RXCIRC4
Extended PDV Monitoring Structure (0-1 per PDV Absorption Structure) DISAS4
RTP Common PDV Absorption Structure (1 per N channels) DISAS9
Note: The Packet Disassembly process has interactions with all the structures on this page. The arrows have not all been drawn for clarity.
Packet Disassembly Control FIFO (global) Packet Disassembly Data FIFO (global)
Packet Disassembly Process
Packet Disassembly Process: Performs dejittering on xxPCM data, copies payload into circular buffer, performs policing on HDLC & CPU channels, reports errors & events in the Event Report Queue.
Clock Recovery Event Queue (2 of them, global) CLKRECOV0-2
Figure 18 - Rx Flow 3
Once the bytes have been copied into the correct circular buffers, only the RX TDM process remains. The RX TDM process is not event-driven with regards to the other processes: by following the Data Flow, we see that, from the Packet Reassembly Process, each process has been triggered by the previous one completing and handing it over the packet. The RX TDM only communicates with the Packet Disassembly process through the TDM pointer. The RX TDM process reads bytes out of the PCM and HDLC circular buffers and places them onto the H.110 bus. Each frame it reads one byte out of each xxPCM circular buffer and places it on the appropriate TSST; it uses a channel association memory to make this connection. It also compensates for underruns and packet losses by inserting SSRAM Tone Buffers, SDRAM Silence Buffers or Padding Octets. In HDLC, when there is no data to be sent on a stream, it sends the idle code.
42
Zarlink Semiconductor Inc.
Data Sheet
RX HDLC Stream Structure (1 per Stream) RXTDM1
MT92210
RX Channel Association Memory (1 entry per TSST) RXTDM0
RX TDM Process
RX xxPCM Buffer Structure (1 per Bearer) RXTDM1 TDM Byte (To H.110) Padding Type Control Memory (1 Entry per SSRAM Tone Pair) TONEMEM0
RX TDM process: Reads bytes from circular buffers and places them onto the H.110 bus, inserts idle code in HDLC if no data is present, pads for underruns/data loss in xxPCM. Tone Copying Process: Copies bytes from each of the 96 tone or silence buffers contained in external RAM to internal memories so they can easily be accesses by the RX TDM process.
Tone Buffer & Padding Octet Memory (global)
SDRAM Silence Buffer Memory (global)
Low Latency Loopback Memory (global)
Tone Copying Process
SSRAM Tone Buffers (global, 32 Pairs)
SDRAM Silence Buffers (global, 32 of them)
Figure 19 - Rx Flow 4
5.2
TX Data Flow
The following section summarizes the typical propagation of voice data throughout the MT92210 in the transmit direction, from the H.110 bus to the packet link. Data from a TSST is read off the H.110 bus and is associated with either an xxPCM buffer or an HDLC stream by the TX channel association memory. This memory can associate up to 1023 TSSTs with up to 1023 xxPCM buffers or 512 HDLC streams. The byte is then treated by the corresponding entry in the TX control memory. In xxPCM, this structure contains the base address and size of the circular buffer to which the TSST is associated. In HDLC, this structure also contains the base address and size of the circular buffer, as well as all the internal context used to perform HDLC de-framing. The byte is then written into its circular buffer.
Zarlink Semiconductor Inc.
43
MT92210
Data Sheet
TX HDLC Stream Structure (1 per Stream) TXTDM1
TX Channel Association Memory (1 entry per TSST) TXTDM0
TX TDM Process
TX xxPCM Buffer Structure (1 per Bearer) TXTDM1 TDM Byte (From H.110)
TX TDM process: Takes bytes from H.110 and writes them into the appropriate circular buffers; does HDLC de-framing and law translation on PCM values.
Figure 20 - Tx Flow 1
In HDLC, when a packet completes, its HDLC stream number is used to index in the HDLC Stream to HDLC Address LUT structure, and from there its HDLC address is used to index into the HDLC Address LUT. This structure, in turn, will point to the TX Connection structure that will be used by the packet assembly block to create the packet. An event is generated directly into the Assembly Event Queue; from there, the packet assembly module reads the event (and with it the address of the TX Connection Structure), then reads the packet payload itself from the HDLC circular buffer, creates the complete packet and writes its data into the Packet Assembly Data FIFO; it also writes the control associated to it in the Packet Assembly Control FIFO. For xxPCM channels, the originator of the Assembly Events is the Service Timer. The Service Timer process scans all the Service Indicator tables and when it hits a valid indicator, writes an assembly event in the assembly event queue. From here it goes to the packet assembly process where a TX Connection structure is used to assemble the packet. The TX Connection structure may point to a TX Silence Suppression structure that would be used to perform silence suppression on the xxPCM samples. In both HDLC and xxPCM, if the packet is RTP, a TX RTP Header Structure will be used to assemble the correct headers at the beginning of the packet. The TX RTP header structure contains the data values of all the headers, all the information needed to assemble the variable headers of the packet, as well as the packet's destination.
44
Zarlink Semiconductor Inc.
Data Sheet
HDLC Stream to HDLC Address LUT Structure (1 entry per stream) TXTDM4 HDLC Address LUT (RTP) (1 entry per HDLC channel) TXTDM5
MT92210
Event indicating HDLC packet complete TX HDLC Circular Buffer (1 per Stream) TXCIRC5
TX xxPCM Circular Buffer (1 per Bearer) TXCIRC4
HDLC Packet Treatment Process
Packet Assembly
TX CPU Packets (CPUmanaged)
Service Indicator Process
Assembly Event Queue (global) EVENTQ0-7
TX RTP Connection Structure (1 per Connection) ASSEM0-1
Identification Counter Source (1 per SRC/DST IP Address pair)
Service Indicator Control Memory (1 entry per Table) SERVTIM1
Service Indicator Table (up to 16, global) SERVTIM0
TX Silence Suppression Structure (1 per PCM channel) SILENCE0
TX RTP Header Structure (1 per Connection) ASSEM2-5
HDLC Packet Treatment Process: When an HDLC packet completes, this process will generate an event pointing to the correct TX RTP Connection Structure, indicating that a packet should be sent to the network. Service Indicator Process: Schedules the Assembly of RTP xxPCM packets. The service timer reads the Service Indicator Tables synchronously with the H.100 bus and generates assembly events when enough payload is present to assemble a complete packet. Packet Assembly: Based on assembly events, generates RTP packets and all the appropriate headers as well. Also performs silence suppression on xxPCM data.
Figure 21 - Tx Flow 2
Once written in the Packet Assembly Control & Data FIFOs, RTP packets will be read by the Assembly Copying Process that then writes the packets into their destination buffer. The payload of RTP packets is written into the Network Packet Buffer, while the handle to the packet is written into one of 6 destinations: one of the 4 TX Link Packet Buffer Handles, the Network CPU Packet Buffer Handles (for internal diagnostic), or the Packet Identifier Buffer Handles (for internal loopback).
Zarlink Semiconductor Inc.
45
MT92210
Data Sheet
RX CPU Raw Cell Buffer Pointers (global) RAWCELL2)
TX link A Raw Cell Buffer 0 Pointers (global) RAWCELL2 TX link A Raw Cell Buffer 1 Pointers (global) RAWCELL2 TX link A Raw Cell Buffer 2 Pointers (global) RAWCELL2
Packet Assembly Control FIFO (global) Packet Assembly Data FIFO (global) CPU cell injection
TX link A Raw Cell Buffer 3 Pointers (global) RAWCELL2 TX link B Raw Cell Buffer 0 Pointers (global) RAWCELL2 TX link B Raw Cell Buffer 1 Pointers (global) RAWCELL2
CPU network packet injection
Assembly Copying Process
TX link A HP Packet Buffer Handles (global) NET6 TX link A LP Packet Buffer Handles (global) NET6
Assembly Copying process: Copies RTP packets from the Packet Assembly Control & Data FIFOs and writes them into SDRAM C; also writes their handles in SSRAM C. CPU cell injection: Software process that writes cells in external SSRAM C then sends its pointer to the correct destination. CPU packet injection: Software process that writes packets into blocks in external SDRAM C, then sends its handle to the correct destination. Network CPU Packet Buffer Handles (global) NET6
TX link B HP Packet Buffer Handles (global) NET6
TX link B LP Packet Buffer Handles (global) NET6
Figure 22 - Tx Flow 3
Raw cells written into one of the TX Link Raw Cell Buffers will be transmitted onto the appropriate TX link port. Raw cells can be transmitted onto any port configured as ATM UTOPIA. Either the TX Link A or TX Link B Copy Process will read the cell from the Raw Cell Buffer and copy it into either the TX Link A Packet/Cell FIFO (for port A) or the TX Link B Cell FIFO (for port B), from where it will be transmitted onto the link. Packets written into one of the TX Link Packet Buffers will also be read out by the corresponding TX Link Copy Process: if port A is configured as Ethernet or Packet over SONET, then the data will be written into the TX Link A Cell FIFO. From there, the Block to Packet Conversion process will write the packet as a contiguous packet into the TX Link A Cell/Packet FIFO, from where it will be transmitted onto the link. If port A is configured as ATM, however, packets will get the same treatment as raw cells: written directly into the TX Link A Packet/Cell FIFO, then to the link. Packets on port B also go through the same treatment as raw cells: they are copied into the TX Link B Cell FIFO and transmitted onto the link.
46
Zarlink Semiconductor Inc.
Data Sheet
MT92210
Used when TX link A is UTOPIA
TX Link A Copy Process
Used when TX link A is Ethernet/POS
TX link A Cell FIFO (global)
TX link A Packet/Cell FIFO (global)
To TX link A
Block to Packet Conversion Process
TX link A Copy process: Copies packets from external SDRAM to the TX link A packet/Cell FIFO, when the link is UTOPIA, or to the TX link A Cell FIFO when the link is Ethernet or POS. Also copies raw cells to the TX link A Packet/Cell FIFO, only when the link is UTOPIA. TX link B Copy process: Copies packets from external SDRAM to the TX link B Cell FIFO. Also copies raw cells to the TX link B Cell FIFO. Block to Packet Conversion Process: When link A is Ethernet or POS, this process will convert the blocks read from SDRAM C and written into the TX link A cell FIFO into contiguous packets which are then written in the TX link A Packet/Cell FIFO. Also takes care of all Ethernet/POS formatting, such as removing the LANEv1 header.
TX Link B Copy Process
TX link B Cell FIFO (global)
To TX link B
Figure 23 - Tx Flow 4
Zarlink Semiconductor Inc.
47
MT92210
Data Sheet
48
Zarlink Semiconductor Inc.
Data Sheet
6.0 Packet Identification
MT92210
Packets received from the network must go through a look-up process to determine what is their destination. The first step in choosing a final destination for a packet is determining its packet type.
RX RTP Connection Structure Base Address Match Binary Tree Post-Search IP Address (global) Confirmation Index Flow (points to an Structure (1 Table (1 entry in the per per No Match Flow Table) connection or logical header) subnet) Profile Default Post-Search Structure (1 per profile)
Profile Memory Entry (Hash Key Mask) (1 per Profile)
Initial Search Structure (1 per packet type)
Next Header Memory (global)
Profile Memory (Option + TOS) (global)
Post-Search Process
Binary Tree Search
Identification Key CRC + hashing
Identification Key (preCRC)
Packet Parsing
Packet Identification Buffer Handles (global)
If the post-search process decides to search for the packet in the binary tree using another profile
If the initial search was for an MPLS label, MPOA tag or ELAN ID, and the result is valid, then the packet will be parsed again, ignoring that header
Figure 24 - Packet Identification
6.1
Packet Types
The two most important decisions are whether or not the received packet is an IP packet, and whether or not it is a null-encapsulated packet. A null-encapsulated packet is a packet that is transported over AAL5 and whose IP and UDP headers are eliminated to save bandwidth. Regular IP packets must also be sub-classified: their IP version (v4 or v6) must be determined, and the protocol used below IP is established. Non-fragmented UDP packets are grouped together in one category, while fragmented packets or non-UDP packets are grouped separately. IP packets with a version other than v4 or v6 are routed separately. Non-IP packets are also routed separately. And lastly, three "special" headers can be decoded and used to take decisions on packets: these are the MPLS label, the MPOA tag, and the LANEv2 ELAN-ID. Table 13 lists all the packet types that MT92210 can identify. Each type has an associated Initial Search Structure, which has a fixed location in SDRAM C. Any received packet must fall into one of the type, and will be handled as per the instructions in Initial Search Structure. Packets that contain one or many of these headers may require multiple look-up iterations before being assigned to their final destination
Zarlink Semiconductor Inc.
49
MT92210
Data Sheet
:
No.
1 2 3 4 5 6 7 8 9 10
Packet Type
Null Application Data or Raw AAL5 Packets Non-IP Packets IPv4 with Non-Fragmented UDP Protocol IPv4 with Fragmented UDP Protocol/non-UDP Protocol/Invalid Protocol IPv6 with Non-Fragmented UDP Protocol IPv6 with Fragmented UDP Protocol/non-UDP Protocol/Invalid Protocol IPvX (Other than version 4 or 6) ELAN-ID Lookup MPOA Look-up MPLS Look-up
Initial Search Structure Address in SDRAM
1000h 1080h 1100h 1180h 1200h 1280h 1300h 1380h 1400h 1480h
ID Key Format
3 1 1 2 2 3 3 3
Table 13 - Packet Types and Initial Search Structures
50
Zarlink Semiconductor Inc.
Data Sheet
MT92210
b31 b30 b29 b28 b27 b26 b25 b24 b23 b22 b21 b20 b19 b18 b17 b16 b15 b14 b13 b12 b11 b10 b9 b8 b7 b6 b5 b4 b3 b2 b1 b0 +0 +4 +8 +C +10 +14 +18 +1C +20 +24 +28 +2C +30 +34 +38 +3C +40 +44 +48 +4C +50 +54 +58 +5C +60 +64 +68 +6C +70 +74 +78 +7C Next Profile
RUN
Match Packet Count [31:0] Match Byte Count [31:0]
RTD
Figure 25 - Format of Initial Search Structure (Refer to Figure 19 for field descriptions)
6.2
Packet Parsing
Before getting to the IP level, the MT92210 must parse through all of the link-layer information and headers contained in the packet. The MT92210 can support packets whose link-layer information begins with an LLC header (Classical IP over ATM, LANE v2), a PPP header (Packet over SONET, PPP over ATM), an Ethernet header (Ethernet, LANE v1), an MPOA tag (MPOA over ATM), an MPLS label, an IP header or application data. It then plows through the successive layers of link layer headers and network headers to extract its identification key made up of a combination of fields such as source and destination addresses, UDP source and destination ports, RTP SSRC, MPLS,/MPOA/ELAN-ID tags as available. The parser gets the very first protocol information from "1st Header" in Packet Reassembly Structure, and is able to find out all following headers therefore determines the packet type automatically. Some IP headers can get special treatment from the packet parser. Specifically, the "next header" field found in IPv6 (and that, in many cases, can also be used as the "protocol" field in IPv4) can force special treatment of the packet, such as deleting it or routing it as a non-UDP packet. In a similar fashion, the "options" field found at the end of the IPv4 header as well as the "options" found in the hop-by-hop options header and the destination options
Zarlink Semiconductor Inc.
51
MT92210
Data Sheet
header can also be used to make decisions regarding the packet. With this ability, the MT92210 can ensure that any packet containing a certain header will be deleted or always sent to the CPU buffer, for example. The information indicating how to treat the various "next header" values is contained in the Next Header memory. The information indicating how to treat the various "options" is contained in the Profile Memory, which will be shown later in Figure 28. The format of the Next Header memory is the following:
b 15 b14 b13 b12 b11 b10 b9 0h NH=0 NH=1 NH=2 b8 b7 b6 b5 b4 b3 b2 b1 b0
NH=3
NH=4
NH=5
NH=6
NH=7
3Eh NH=248 NH=249 NH=250 NH=251 NH=252 NH=253 NH=254 NH=255
Figure 26 - Next Header Memory
Field
NH
Description
Next header. Indicates what to do when the hardware encounters this "next header" value. "00" = delete; "01" = route as non-UDP / fragmented UDP (to software); "10" = process next header in IPv6 only; "11" = process next header in IPv4 and IPv6.
Table 14 - Fields and Description
6.3
Look-up
Once the type of the packet has been found, it must be searched for in the look-up system. The packet will initially be routed to a default node (i.e. the Initial Search Structure), depending on its packet type (see Table 13 for the exhaustive list). The default node is the first step in deciding what to do with the packet: it may indicate that the packet must be discarded, routed to the CPU packet buffer or routed back onto the network on ports A or B. It may also indicate that a more detailed search must be performed on the packet: in this case, the packet will be looked-up in a binary tree. Usually, the default node will only indicate a destination for broad classes of packets that the chip cannot process itself: for example, IPvX packets, or non-IP packets. In the case of IP/UDP packets, the binary tree search should always be performed. If a tree search is to be performed, the default node will indicate which profile to use. The MT92210 uses a binary tree approach to uniquely identify packets: each packet is given a 60-bit identification key generated by performing a 56-bit CRC on the various protocol headers that it contains and completed by adding the 4-bit profile number to the key. The headers used to generate the source key depend on the nature of the packet: while non-IP packets cannot even be passed through the binary tree, for lack of recognizable headers, null-encapsulated packets can only use the Flow Table Pointer associated to the packet and the RTP synchronization source to form the identification key (if RTP is not present, the Flow Table Pointer alone will be used). Non-UDP and fragmented packets will have a identification key based only on their source and destination IP addresses. Finally, the identification key for IP/UDP packets will include the source and destination IP addresses, source and destination UDP ports, and potentially the RTP synchronization source. The packet type determines which of the three identification key formats be selected.
52
Zarlink Semiconductor Inc.
Data Sheet
MT92210
Format 1 - IPv4, UDP, RTP (Length = 4) b31 b30 b29 b28 b27 b26 b25 b24 b23 b22 b21 b20 b19 b18 b17 b16 b15 b14 b13 b12 b11 b10 b9 b8 b7 b6 b5 b4 b3 b2 b1 b0 +0 +4 +8 +C Source IP Address [31:0] Destination IP Address [31:0] First word of IP Payload - UDP Source Port [15:0] Second word of IP Payload - UDP Destination Port [15:0]
Third Dword of UDP Payload - SSRC [31:0] Format 2 - IPv6, UDP, RTP (Length = 10) b31 b30 b29 b28 b27 b26 b25 b24 b23 b22 b21 b20 b19 b18 b17 b16 b15 b14 b13 b12 b11 b10 b9 b8 b7 b6 b5 b4 b3 b2 b1 b0
+0 +4 +8 +C +10 +14 +18 +1C +20 +24
Source IP Address [127:96] Source IP Address [95:64] Source IP Address [63:32] Source IP Address [31:0] Destination IP Address [127:96] Destination IP Address [95:64] Destination IP Address [63:32] Destination IP Address [31:0] First word of IP Payload - UDP Source Port [15:0] Second word of IP Payload - UDP Destination Port [15:0]
Third Dword of UDP Payload - SSRC[31:0]
Format 3 - AAL5 Null Encapsulation with RTP, AAL5 raw packets, MPLS Look-up, MPOA look-up (Length = 4) b31 b30 b29 b28 b27 b26 b25 b24 b23 b22 b21 b20 b19 b18 b17 b16 b15 b14 b13 b12 b11 b10 b9 b8 b7 b6 b5 b4 b3 b2 b1 b0 +0 +4 +8 +C Flow Table Bit Pointer [23:0] Third dword of packet - SSRC [31:0] / ELAN-ID [31:0] MPLS Shim [19:0] MPOA Tag [31:0]
Figure 27 - Identification Key Formats (before CRC)
6.4
Masking
Before the CRC is performed on the identification key, a mask will be applied to it, depending on the profile used to search for the packet. This mask prevents certain values from being included in the final identification key. For example, if a profile wants to search for packets using only the IP source and destination addresses and the UDP source and destination ports, but not the SSRC, then dword 3 of the identification key will be masked out and the others will be allowed to pass. The mask used with each profile is contained in the Profile Memory, whose format is the following:
Zarlink Semiconductor Inc.
53
MT92210
0h 40h
Data Sheet
Profile Entry 0 Profile Entry 1
380h 3C0h
Profile Entry 14 Profile Entry 15
Profile Entry b31 b30 b29 b28 b27 b26 b25 b24 b23 b22 b21 b20 b19 b18 b17 b16 b15 b14 b13 b12 b11 b10 b9 b8 b7 b6 b5 b4 b3 b2 b1 b0 +0 +4 +8 +C +10 +14 +18 +1C +20 +24 +28 +2C TOSv4_0 TOSv4_1 TOSv4_2 +30 +34 +38 v4_0 Hop0 Dst0 v4_1 Hop1 Dst1 v4_2 Hop2 Dst2
TOSv4_15
Hash Key Mask Dword 0 Hash Key Mask Dword 1 Hash Key Mask Dword 2 Hash Key Mask Dword 3 Hash Key Mask Dword 4 Hash Key Mask Dword 5 Hash Key Mask Dword 6 Hash Key Mask Dword 7 Hash Key Mask Dword 8 Hash Key Mask Dword 9
v4_15 Hop15 Dst15
TOSv6_15
+3C TOSv6_0 TOSv6_1 TOSv6_2
Figure 28 - Profile Memory
Field
Hash Key Mask Dword
Description
This mask will be applied to the identification key before a CRC is applied to it. When `0', the corresponding bit in the identification key will be masked to `0'. When the identification key is only 4 dwords long, dwords 4 - 9 in this mask are ignored. Indicates what to do when the hardware encounters these option values. "00" = unknown/no decision; "01" = skip to end; "10" = CPU through fragmented IP; "11" = delete. Each profile entry contains the treatment values for Options N*16 to N*16+15, where N is the profile entry number. In this way, all 256 values for the options are treated. These values are not in any way linked to the profile; they just reside in the same memory.
Option Header Treatment v4_X - IPv4 option field HopX - IPv6 hop-by-hop header option DstX - IPv6 destination header option
Table 15 - Fields and Description
54
Zarlink Semiconductor Inc.
Data Sheet
"Type of Service" Treatment TOSv4_X - IPv4 TOS field TOSv6_X - IPv6 TOS field Indicates what to do when the hardware encounters these TOS values. "00" = don't change priority; "01" = reserved; "10" = change packet priority to low priority; "11" = change packet priority to high priority. Each profile entry contains the treatment values for TOS N*16 to N*16+15, where N is the profile entry number. In this way, all 256 values for the TOS are treated. These values are not in any way linked to the profile; they just reside in the same memory.
MT92210
Table 15 - Fields and Description
6.5
Post-search Confirmation
Once the mask has been applied, the CRC calculated, and the profile number added, the resulting 60-bit identification key is then used to navigate through the binary tree until the node containing that key is found. When this node is found, it is associated to a post-search confirmation structure that tells the look-up system if the node actually corresponds to the headers of the given packet (because a CRC is performed, collisions between various CRC can occur). The post-search confirmation structure contains a copy of the headers used to form the identification key. When a packet hits a post-search confirmation structure, its headers are compared to the headers contained in the structure: if they match, the packet belongs to that structure. One last verification is done before the packet is completely validated: its IP address index is looked up in the Flow Table pointed to by the packet's Flow Table Pointer. The Flow Table is used to verify if the destination IP address of the packet is a legal address to be received on this logical subnet. If the match is `1', then the packet is valid and is sent to the Routing Destination indicated by the post-search confirmation structure. If the match is `0', then the packet has failed the post-search verification and continues to be searched. The Flow Table look-up is optional, and should not be performed when trying to match structures that don't have a destination IP address, for instance if an MPLS label is being searched, or a packet containing RTP over AAL5. The format of the Flow Table is as follows:
b31 b30 b29 b28 b27 b26 b25 b24 b23 b22 b21 b20 b19 b18 b17 b16 b15 b14 b13 b12 b11 b10 b9 b8 b7 b6 b5 b4 b3 b2 b1 b0 +0 +4 +8 +C +10 +14 +18 +1C I224 I253 I254 I255 I0 I1 I2 I31
Figure 29 - Flow Table
Zarlink Semiconductor Inc.
55
MT92210
Field
I0 - I255
Data Sheet
Description
Index 0 to 255 in the flow table. The base address of the Flow Table is pointed to by the Flow Table Pointer. The Index is the IP Address Index from the post-search confirmation structure. When `1', the destination IP address of the packet is valid to receive on this logical subnet. When `0', it is invalid.
Table 16 - Fields and Description
If the confirmation structure found does not match the desired headers or the packet fails the Flow Table look-up, the structure may contain a pointer to the Next Post-Search Confirmation Structure and the matching process begins again. If no match is found and the pointer to the next structure is null, then the packet is routed according to the Default Profile Post-Search Structure routing for that profile. Because conflicts are resolved by the post-search confirmation structures, no conflicts can occur in the binary tree, so every node value can only be present once in the tree. Each profile has a Default Post-Search Structure locating at a fixed address in SDRAM C. Any packet that didn't find a match in binary tree, or failed the verification in Post-Search Confirmation Structures, will find its way to Default Post-Search Structure with its profile number. From there, the packet can be deleted, sent to CPU, or re-entering the binary tree by using a new profile number (i.e. a new identification key). The following table and figure show the location and format of Profile Default Post-Search Structures.
Profile number
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Profile Default Post-Search Structure Address in SDRAM
1800h 1880h 1900h 1980h 1A00h 1A80h 1B00h 1B80h 1C00h 1C80h 1D00h 1D80h 1E00 1E80 1F00 1F80
Table 17 - Profile Default Post-Search Structure
56
Zarlink Semiconductor Inc.
Data Sheet
MT92210
b31 b30 b29 b28 b27 b26 b25 b24 b23 b22 b21 b20 b19 b18 b17 b16 b15 b14 b13 b12 b11 b10 b9 b8 b7 b6 b5 b4 b3 b2 b1 b0 +0 +4 +8 +C +10 +14 +18 +1C +20 +24 +28 +2C +30 +34 +38 +3C +40 +44 +48 +4C +50 +54 +58 +5C +60 +64 +68 +6C +70 +74 +78 +7C Next Profile
RUN
FFFFh
FFFFh
Match Packet Count [31:0] Match Byte Count [31:0]
RTD
Figure 30 - Format of Profile Default Post-Search Structure (Refer to Table 19 for field descriptions)
The binary tree used is a dynamically re-balanceable tree, which means that the tree's nodes are always in the optimal distribution, minimizing search times. In addition, to minimize the impact of conflicts, two binary trees exist simultaneously in the system: one is active and used by the chip, while the other one is inactive. When the CPU decides that the current binary tree contains too many nodes with conflicts in them, it can re-create a binary tree by adding a random 32-bit number to each header dword used in the calculation of the key. This method provides a whole new distribution that is statistically very unlikely to have the same conflict problems as the original tree. The CPU can then switch the trees. The inactive one becomes active and vice-versa, and the chip beings using the new tree. Register F18h points to the root node of binary tree. This is the format of the binary tree nodes:
Zarlink Semiconductor Inc.
57
MT92210
LA [20] RA [20]
Data Sheet
b31 b30 b29 b28 b27 b26 b25 b24 b23 b22 b21 b20 b19 b18 b17 b16 b15 b14 b13 b12 b11 b10 b9 b8 b7 b6 b5 b4 b3 b2 b1 b0 +0 +4 +8 +C Left Address [19:4] Profile Header CRC Key [55:32] Header CRC Key [31:0] Right Address [19:4] First Post-Search Confirmation Structure Address [24:7]
Figure 31 - Binary Tree Node
Field
Header CRC key Profile LA RA First Post-Search Confirmation Structure Address
Description
Bits 55:48 represent a CRC-8 of the initial identification key. Bits 47:32 represent a CRC-16 of that same key, and bits 31:0 represent a CRC-32 of that same key. Profile number being used to perform packet search. The profile number and header CRC key, between them, represent the 60-bit identification key used to search for the packet. Address of left node below the current node. The left node will contain an identification key that is smaller than the current one. Address of right node below the current node. The right node will contain an identification key that is larger than the current one. Indicates the address of the post-search confirmation structure that will be used to route this packet if it matches the identification key.
Table 18 - Fields and Description
When the correct node associated with the packet is found, the post-search confirmation structure will indicate what course of action to take concerning the packet. It may indicate to route the packet to the Packet Disassembly, to the RX CPU buffer or onto network port A or B. It may also indicate that another look-up needs to be performed, this time using a different look-up profile. The process then begins anew using the new profile Other look-ups can take place in the binary tree: for example, ELAN-IDs contained in LANE v2 packets can be looked up, along with the Flow Table Pointer. A CRC will be performed on the fields, a 60-bit key will be generated, and a post-search entry will be obtained. This entry can be used to modify the Flow Table Pointer and the parsing of the packet will then continue with the new pointer. MPOA tags and MPLS labels can also be searched for in the binary tree and post-search structures: apart from modifying the Flow Table Pointer, these searches are also used to identify the nature of the protocol above MPOA or MPLS. When packets are first assembled in the AAL5 reassembly structure, the nature of the protocols above these two are tagged in the fields MPLS_IP and MPOA_IP. When an MPOA or MPLS header is found in the packet and the nature of the following protocol has not been established, this header is looked-up along with the Flow Table Pointer. The resulting structure will identify the following protocol and may also change the Flow Table Pointer. The packet analysis then strips the MPOA or MPLS header off and continues the binary tree search with the following protocol. To demonstrate the operation of this system, here is a simulation of the arrival of a packet in the packet identifier module. The packet arrives from RX link A and is an IPv6 voice packet carrying UDP and RTP. When parsed by the look-up module, its version number is established (6) and its IP header is searched until the protocol being carried (UDP) is found. The packet is then classified as an IP/UDP packet and routed using the default note which points to the Initial Search Structure for that type of packet, in this occurrence the structure at address 1200h. The Initial Search Structure indicates that a binary tree search should be performed using a default profile #5. The profile entry is consulted and it indicates which fields should be used in the binary tree search through a series of mask fields. The mask fields depend on the default configuration of the packet type: for an IPv6 packet with UDP, the default headers are the Source and Destination IP address, Source and Destination UDP port and RTP
58
Zarlink Semiconductor Inc.
Data Sheet
MT92210
synchronization source. In this example, the look-up will be performed using only the Destination IP address and Destination UDP port; which associates with profile #11, the other fields will be masked out. The entire 320-bit masked identification key is then passed through a series of CRC calculations that produce a 56-bit result. These CRC calculations consist of a CRC-32, a CRC-16 and a CRC-8. In addition, before passing the identification key through the CRC calculations, a 32-bit value can be added to each dword. This will allow conflict resolution if the binary tree starts getting clogged with too many conflicting nodes: adding a 32-bit value scrambles all the CRC to new random values and old conflicts will likely not reappear. Finally, the 4-bit profile value is annexed to the CRC to produce a 60-bit identification key. This 60-bit result is then used as the new identification key for the binary tree procedure. The binary tree can have up to 128K nodes, distributed in any way. The system finds the node in the binary tree whose key is the same as the one being searched for: it may also find no matching node. Once the binary tree search is complete, the matching node's post-search confirmation structure is looked-up: it is checked to see if the headers of the looked-up packet match those in the confirmation structure, validating the node as being the correct search node. In this case, it can be assumed that there was a node in the binary tree that matched the packet, it matched in the corresponding post-search structure (there cannot be more than one match per packet in the post-search structures: this would be a fatal configuration error and would be flagged to a status bit in registers). The format of the post-search confirmation structure is indicated in the next figure.
Zarlink Semiconductor Inc.
59
MT92210
Data Sheet
b31 b30 b29 b28 b27 b26 b25 b24 b23 b22 b21 b20 b19 b18 b17 b16 b15 b14 b13 b12 b11 b10 b9 b8 b7 b6 b5 b4 b3 b2 b1 b0 +0 +4 +8 +C +10 +14 +18 +1C +20 +24 +28 +2C +30 +34 +38 +3C PSA[8:7] PRA PRB IP Address Index(in Flow Table) [7:0] +40 LHR HP LHR LP +44 +48 +4C +50 +54 +58 +5C +60 +64 +68 +6C +70 +74 +78 +7C UU LP [7:0] UU HP [7:0] New ATM Header HP [31:0] CPI HP [7:0] New ATM Header LP [31:0] CPI LP [7:0] SIP AIP CF ER CP NP Flow Table Pointer [23:0] Match Packet Count [31:0] Match Byte Count [31:0] Next Post-Search Confirmation Structure Address [24:9] Next Profile LHR RX RTP Connection Structure Base Address [20:5]
FTE RUN
Identification Key Dword 0 Identification Key Dword 1 Identification Key Dword 2 Identification Key Dword 3 Identification Key Dword 4 Identification Key Dword 5 Identification Key Dword 6 Identification Key Dword 7 Identification Key Dword 8 Identification Key Dword 9
RTD
Figure 32 - Post-Search Conformation Structure
60
Zarlink Semiconductor Inc.
Data Sheet
Field
Identification key dword 0-9
MT92210
Description
The initial (pre-CRC) identification key of the packet should match these fields for the packet to be declared valid with this post-search structure. Note that fields which are masked out by the Profile Identification Mask should be set to 0s in this structure. The format of the identification keys is indicated in Figure 27. MPLS IP indicator. "11" = reserved; "10" = RTP/UDP payload; "01" = IP, "00" = no change. MPOA IP indicator. "11" = RTP/UDP payload, "10" = IP, "01" = MPLS unicast, "00" = no change. Change Flow. When `1', the Flow Table Pointer in this structure will be used to replace the one to which the packet was associated. ELAN-ID Resolved Indication. When `0', the ELAN-ID Resolved Indicator is left unchanged. When `1', the ELAN-ID Resolved Indicator is positively identified as resolved. Change Priority of packet. When `1', the priority of the packet will be changed. new priority of packet (if it was changed). `0' = LP; `1' = HP. This field represents the logical subnet number on which the packet is received. This value will replace the current Flow Table Pointer of the packet if the CF (Change Flow) bit = `1'. Number of packets that matched this post-search confirmation structure. Number of bytes contained in all packets that matched this post-search confirmation structure (based on Total Packet Length in packet handle). If a packet hits this post-search structure and does not match, this pointer points to the next structure that it can try to match with. This field is only used when more than 1 post-search confirmation structure is associated to the same binary tree node, meaning that different headers produced the same CRC. 0000h means Null link. If the packet matches this post-search confirmation structure and its Routing Destination field includes the Disassembly module as a destination, this is the RTP Connection Structure that will be used. Priority Route A. If this bit is high, the priority of the packet determines if it will be sent to TXA HP or TXA LP packet queue. When this bit is high, the RTD bits for TXA HP and TXA LP are ignored. Priority Route B. If this bit is high, the priority of the packet determines if it will be sent to TXB HP or TXB LP packet queue. When this bit is high, the RTD bits for TXB HP and TXB LP are ignored. This index points to an entry within the Flow table that corresponds to the Destination IP address of this packet. Note that the old Flow Table Pointer will be used to look-up the IP Address Index, even if the Flow Table Pointer is changed by this structure.
SIP
AIP
CF ER
CP NP Flow Table Pointer
Match Packet Count Match Byte Count Next Post-Search Confirmation Structure Address RX RTP Connection Structure Base Address PRA
PRB
IP Address Index (in Flow Table)
Table 19 - Fields and Description
Zarlink Semiconductor Inc.
61
MT92210
Field
Next Profile LHR FTE RUN
Data Sheet
Description
When this structure matches and the RUN (Route Using Next profile) bit is `1', this is the profile number that will be used to search for the packet in the binary tree. Link Header Replace. When `1', the ATM header and UU/CPI may be changed before the packet is routed to its destination(s). When `1', the flow table will be consulted to know if the hit is valid. Route Using Next profile. When `1' and the packet matches this post-search confirmation structure, it will be searched for in the binary tree using Next Profile as a profile number. Routing Destination. "000000000" = Delete; "1xxxxxxxx" = reserved; "x1xxxxxxx" = TX Link A HP; "xx1xxxxxx" = TX Link A LP; "xxx1xxxxx" = TX Link B LP; "xxxx1xxxx" = TX Link B HP; "xxxxx1xxx" = reserved; "xxxxxx1xx" = Network CPU Packet Buffer; "xxxxxxx1x" = Disassembly; "xxxxxxxx1" = Packet Identifier; others = reserved. Indicates whether this packet's ATM header and UU/CPI should be changed when the packet is routed in high priority. "1x" = change ATM header, "x1" = change UU/CPI. When one of these bits is `1', LHR must also be `1'. Indicates whether this packet's ATM header and UU/CPI should be changed when the packet is routed in low priority. "1x" = change ATM header, "x1" = change UU/CPI. When one of these bits is `1', LHR must also be `1'.
RTD
LHR HP
LHR LP
Table 19 - Fields and Description
The matching confirmation structure is then consulted to determine the fate of the packet: in this case, the structure indicates that a new search should be performed, using another profile! The new profile entry is consulted and it requires a search using the Destination IP address, the Source IP address, the Destination UDP port, and the source UDP port. The new key is then generated using the CRC and profile number and searched for in the binary tree. The hit is then compared to the matching post-search confirmation structure which, in this case, indicates that a new search should be performed again with another profile number. Then the chip will repeat the above search procedure with using the Destination IP address and the Destination UDP port, and come back to the matching post-search confirmation structure. This time, the required destination is the packet disassembly module. Thus the packet is sent to the disassembly module and the next packet can be treated.
62
Zarlink Semiconductor Inc.
Data Sheet
7.0 Packet Assembly
MT92210
The MT92210 packet assembly module is responsible for collecting the bytes written in the circular buffers by the TX TDM and assembling them into RTP packets. Bytes will usually be encapsulated into RTP, UDP and IP, and then be shipped off on Ethernet, ATM or Packet over SONET; the packet assembly can also support a multitude of other header combinations. In addition to generating voice packets, the packet assembly must also perform silence suppression calculations on the incoming bytes to determine if the RTP packets it assembles should be transmitted or not. All of this must be scheduled correctly so that packets are generated at correct times and silence suppression information is available when necessary.
7.1
Service Timer
To ensure that all events in the packet assembly occur on time, the module contains a connection service timer that times both PCM packet assembly events and silence suppression treatment. The principle of the service timer is the following: a service timer is contained in external memory and has a length of N indicators. M indicators are read every frame. Therefore, the service timer is cyclic over N/M frames. Note that up to 16 service timers can be contained in external memory, each one of which can have any length N and any M. Each time the TDM write pointer increments, it generates a pulse indicating to the service timer to read an entire frame of the service timer. Thus M event indicators are read and each of them can request the packet assembly module to try to assemble an xxPCM packet, and optionally, perform silence suppression calculations on a block of PCM data. The service timer must schedule events in such a way as to minimize the end-to-end delay that CBR data encounters through the system. For example, if each RTP packet on a given connection contains 80 bytes of payload from a single channel, then an event signaling the assembly of one of these packets will be contained in a service timer of 80 frames in length. Thus, this event will be scheduled to occur once every 80 frames, matching the data rate of the incoming TDM traffic. Because the number of frames in an RTP packet can vary and that finding a combination of 16 service timer lengths that could accommodate all possible frame fills between 1 and 1500 would be impossible, the events indicating packet assembly do not force the transmission of a packet. Instead, they indicate to the assembly module to attempt the assembly of a packet. The module will verify what is the current value of the TDM pointer and where the previous packet assembly ended, and based on this, will determine if enough TDM bytes are available to generate the desired packet. If a limited number of packet sizes is used, then the 16 service timers may be able to accommodate all connections in an exact way, adding no extra delay. Because the assembly of RTP packets containing HDLC data is asynchronous, it does not need to be scheduled in the service indicator. When the service timer requests a packet assembly, the event may be preceded by a silence suppression calculation event. For channels on which silence suppression is performed, a separate process takes care of reading the local and remote PCM bytes from their circular buffers, performing energy calculations on them and returning a silent/non-silent result so that the assembly module knows whether or not to send packets containing that channel. The silence suppression calculations are performed on blocks of the same size as the number of frames of data contained in the RTP packet in which these bytes will be transmitted. In this manner, the silence suppression event makes sure that the suppression decision (send / suppress) is up to date when the packet is transmitted or not transmitted. Silence suppression can only be used with connections carrying a single channel. The service timers are configured is in an internal memory that contains 16 entries. The format of this internal memory is the following:
Zarlink Semiconductor Inc.
63
MT92210
Data Sheet
2C00h 2C08h 2C10h
Service Timer Descriptor 0 Service Timer Descriptor 1 Service Timer Descriptor 2
2C68h 2C70h 2C78h
Service Timer Descriptor 13 Service Timer Descriptor 14 Service Timer Descriptor 15
Service Timer Descriptor b15 b14 b13 b12 b11 b10 b9 +0 +2 +4 +6 b8 b7 b6 b5 b4 b3 b2 b1 b0 Phase Base Address [20:11] Indicators per Frame
Service Timer Base Address [20:5] Next Indicator to be Read [15:0] Last Indicator Number [15:0]
Figure 33 - Service Timer Control Memory
Phase Base Address Indicators per Frame Service Timer Base Address Next Indicator to be Read Last Indicator Number Points to a circular buffer that contains phase octets. An address of zero means no phasing is applied. This field determines how many indicators are read per TDM bus frame. This field pointer to the first entry of the Service Timer in external SSRAM A. This pointers is in increments of 32 bytes. The field tells the hardware which indicator is next to be read in the Service Timer. This field should be initialized to zero at startup. This field defines the length of the Service Timer in increments of 1 Indicator entry. A Service Timer of 64 indicators in length would require this field to be set to 63.
Table 20 - Fields and Description
64
Zarlink Semiconductor Inc.
Data Sheet
The format of the service timer in external memory is the following:
MT92210
+0 +4 +8
Indicator 0 Indicator 1 Indicator 2
+(N-3)*4 +(N-2)*4 +(N-1)*4
Indicator N-3 Indicator N-2 Indicator N-1
N = {1 - 65536} Start Boundary = 16 bytes
Unused Indicator b 15 b14 b13 b12 b11 b10 b9 +0 +2 0 0
b8
b7
b6
b5
b4
b3
b2
b1
b0
Generate Assembly Event - Service xxPCM RTP Channel b 15 b14 b13 b12 b11 b10 b9 b8 b7 b6 b5 b4 b3 +0 +2 0 1 Serv Timer # Assembly Structure Base Address [20:6]
b2
b1
b0
ST
Table 21 - Service Timer
Zarlink Semiconductor Inc.
65
MT92210
Field
Serv Timer # ST: Assembly Structure Base Address [20:6] Service Timer number
Data Sheet
Description
Start Channel. A channel will only power-up on an event that has this bit set to `1'. Base address of the Tx RTP Connection Structure to which this event is being sent. The base address is pointed to in increments of 64 bytes.
7.2
Event Queue
When events indicating the assembly of RTP packets are read and treated by the service timer, they are written into a packet assembly queue to be treated in order. HDLC packets that complete also generate events in this packet assembly queue independently of the service timer. The CPU can also generate packets to be inserted in an active connection. To do so, it writes the packets' payload in external memory (including the RTP header if any), and writes a descriptor to registers. This descriptor is then inserted into the event queue and treated by the chip. By inserting packets into an active connection instead of constructing the packets entirely itself, it allows the chip to manage the consistency of the RTP header across packets. For example, the sequence number will be incremental across all packets on an IP/RTP connection, not just on voice packets generated by the chip.
+0 +10 +20
Assembly Event 0 Assembly Event 1 Assembly Event 2
+(N-3)*10h +(N-2)*10h +(N-1)*10h
Assembly Event N-3 Assembly Event N-2 Assembly Event N-1
N = {1024, 2048, 4096} Start/Cross Boundary = {16K, 32K, 64K} bytes
Figure 34 - Assembly Event Queue
66
Zarlink Semiconductor Inc.
Data Sheet
b 15 b14 b13 b12 b11 b10 b9 +0 +2 +4 +6 +8 +A +C +E 0 TI Buf Size 1 0 0 0 Assembly Structure Base Address [20:6] CPU Packet Base Address [20:5] TDM Write Pointer [13:0] CPU Packet Length [10:0] Time Stamp [31:16] Time Stamp [15:0] b8 b7 b6 b5 b4 b3 b2 b1 b0
MT92210
Figure 35 - Assembly Event - Send HDLC RTP Packet Field
HDLC Stream Number Assembly Structure Base Address HDLC Packet Base Address TI
Description
Number of the HDLC Stream structure in the TX TDM Control Memory that generated this event structure. Base address of the Tx RTP Connection Structure to which this event is being sent. The base address is pointed to in increments of 64 bytes. Pointer to the first byte of the HDLC packet in external memory. This pointer points to 32-byte increments in SSRAM A. Time stamp Insert. When `0', the time stamp will be inserted in the packet as it is received in the HDLC packet. When `1', the time stamp in the HDLC packet will be treated as an offset from the current bus time-stamp. TDM Write Pointer used to write xxPCM samples in the TX Circular Buffers at the time of the generation of this event. Size of the HDLC circular buffer in which the HDLC packet is contained. Length of the payload of the HDLC packet in bytes. Local Bus Time Stamp during which the HDLC packet completed.
TDM Write Pointer Buf Size HDLC Packet Length Time Stamp
Table 22 - Fields and Description
Zarlink Semiconductor Inc.
67
MT92210
b 15 b14 b13 b12 b11 b10 b9 +0 +2 +4 +6 +8 +A +C +E Time Stamp [31:16] Time Stamp [15:0] 0 TDM Write Pointer [13:0] 0 1 Assembly Structure Base Address [20:6] ST b8 b7 b6 b5 b4 b3 b2 b1 b0
Data Sheet
Figure 36 - Assembly Event - Service xxPCM RTP Channel Field
Assembly Structure Base Address ST
Description
Base address of the Tx RTP Connection Structure to which this event is being sent. The base address is pointed to in increments of 64 bytes. Start bit. When this bit is set, the first packet of an xxPCM channel can be sent. If an event is received by an TX Connection structure with xxPCM channel waiting to startup (i.e. I bit is cleared), only events with the ST bit set will allow the first packet to be sent out (other event will be ignored). TDM Write Pointer used to write xxPCM samples in the TX Circular Buffers at the time of the generation of this event. Local Bus Time Stamp during which the HDLC packet completed.
TDM Write Pointer Time Stamp
Table 23 - Fields and Description
b 15 b14 b13 b12 b11 b10 b9 +0 +2 +4 +6 +8 +A +C +E 0 TI Buf Size 1 0 0 0
b8
b7
b6
b5
b4
b3
b2
b1
b0
Assembly Structure Base Address [20:6] CPU Packet Base Address [20:5] TDM Write Pointer [13:0] CPU Packet Length [10:0] Time Stamp [31:16] Time Stamp [15:0]
Figure 37 - Assembly Event - Send CPU RTP Packet
68
Zarlink Semiconductor Inc.
Data Sheet
MT92210
Field
Assembly Structure Base Address CPU Packet Base Address TI
Description
Base address of the Tx RTP Connection Structure to which this event is being sent. The base address is pointed to in increments of 64 bytes. Pointer to the first byte of the CPU packet in external memory. This pointer points to 32-byte increments in SSRAM A. Time Stamp Insert. When `0', the time stamp will be inserted in the packet as it is received in the CPU packet. When `1', the time stamp in the CPU packet will be treated as an offset from the current bus time-stamp. TDM Write Pointer used to write xxPCM samples in the TX Circular Buffers at the time of the generation of this event. Size of the CPU circular buffer in which the CPU packet is contained. Length of the payload of the CPU packet in bytes. Local Bus Time Stamp during which the CPU packet was queued.
TDM Write Pointer Buf Size CPU Packet Length Time Stamp
Table 24 - Fields and Description
7.3
RTP Packets
PCM, HDLC and CPU-generated packets are all treated by the same structure, the TX RTP connection structure. Most of the fields of this structure manage the encapsulation protocols used (IP, UDP and RTP) as well as containing the link header. The TX RTP connection structure also contains a pointer to a secondary structure, the TX RTP header structure. This structure contains all protocol-related information, as well as anything that might need to be changed dynamically. By having a pointer to another structure, a new TX RTP header structure can be created with new headers and new characteristics for the packet; once this is done, the pointer in the connection structure can be modified, creating a glitch-free change between the two.
7.3.1
TX RTP Header Structure
The TX RTP header structure contains a number of header words (note that headers for any layer at the network level or above are multiples of dword in length, while link headers can be byte multiples). The structure can indicate different types of encapsulation: IPv4 with UDP and with/without RTP, IPv6 with UDP and with/without RTP, or null encapsulation with/without RTP. In addition, the header words in the structure will contain a SNAP/LLC, LANE/Ethernet, LANE v2 or PPP header, or begin directly with IP, MPOA, MPLS or application data, depending on the type of the connection on which the packet will be sent.
7.3.2
Header Length
The Header Length shows how many bytes of total header will be present in the packet, including link header. This can vary from very short (a few bytes, in the case of ATM carrying null encapsulated data) to very long (when using, for example, Ethernet 802.1 p/Q with IPv6/UDP/RTP and many extension headers). The first 48 bytes of the header are reserved for ATM fields: the ATM header is contained in the first dword of link header and the first 2 bytes of the second dword contain the CPI and UU fields. These will always be ignored in Ethernet or PPP. The other 42 bytes are not used. After the ATM header, the rest of the link header follows and can be between 0 and 255 bytes in length, as indicated by Link Header Length. This length includes the 48 bytes used for the ATM header, UU and CPI, independently of whether the link is Ethernet, PPP or ATM. Note that the IP and RTP headers are always a multiple of 4 bytes in length, and the UDP header is always 8 bytes, while the link header can end on any byte boundary. In the structure, padding bytes and will be added to the link header: it must always end on a dword
Zarlink Semiconductor Inc.
69
MT92210
Data Sheet
boundary. The padding bytes will be ignored when the packet is transmitted on the bus. The Header Length is in dword, including the padding octets.
7.3.3
Packet Type
The Packet Type indicates with which header packets on the connection begin. The values are: "0000" = LLC, "0001" = PPP, "0010" = IP, "0011" = MPLS Unicast, "0100" = MPLS Broadcast, "0101" = MPOA, "0110" = LANEv1/Ethernet, "0111" = Application data. The most exceptional type is 7, because in this mode no IP or UDP headers are contained in the packet, meaning that several fields calculated by the chip, like IP lengths, UDP checksum, and others, do not need to be calculated.
7.3.4
Identification Counter Source Address
The Identification Counter Source Address field is used when a valid Identification value must be generated in the IP header. This is always the case in IPv4 and sometimes the case in IPv6 to allow transparent conversion between IPv6/IPv4 networks. The Identification value must be incremented for each packet that is transmitted. However, because CPU-generated packets must also use the same pool of identification values, a mechanism is put in place to allow the two to share it. Up to 214 identification values can be contained in external memory, and each connection, when it transmits a packet, uses the current value of the identification indicated by Identification Counter Source Address and increments it by 1 after having transmitted the packet. The CPU may also access these values in an uninterrupted way to seize values for its own packets (see the identification_seize registers for more information on this mechanism). The IDentification Enable bit indicates if these identification values should be generated. The ID v6 Position points, in a relative way to header dword 0 within the header structure, to the dword in which the identification field is contained.
7.3.5
UDP Header Start
The UDP Header Start indicates how long the IP header is (in dword) and where the UDP checksum must be inserted in the packet. In the word that would contain the UDP checksum, a partial checksum must be written that contains the one's complement sum of the IP source and destination addresses, as well as the protocol (11h, meaning UDP). This is necessary because, in IPv6, the UDP checksum is not calculated on the IP destination address as indicated in the IP header, but on the final destination address, which may be contained in extension headers.
7.3.6
Timestamp Offset
The Timestamp Offset is a value that must be added to the generated RTP timestamp in the packet. Timestamps are generated differently in PCM, HDLC and CPU packets. This offset ensures that an outside observer cannot predict the timestamp; this offset should be set to a random value when the connection is initialized.
7.3.7
Sequence Number
The Sequence Number is incremental and is incremented and generated for all packets regardless of their source. This means that HDLC and CPU packets that generate an RTP header will have their Sequence Number thrown out and replaced by the one generated by this structure. The Sequence Number Insert bit indicates whether or not the sequence number will be inserted by the chip for HDLC and CPU-sourced packets. If this bit is '0', then the sequence number coming from the packets will be kept. Note that in this case, no PCM packets can be generated on this connection (i.e. ALL sequence numbers will be externally generated).
7.3.8
Transmitted Packet Count
The Transmitted Packet Count is a 16-bit counter indicating the number of packets that have been generated on this connection since its startup. The Transmitted Octet Count is a 32-bit counter of the number of payload bytes generated in packets on this connection. This only includes payload, but it will also include any RTP headers present in CPU or HDLC packets that are seen by the system as payload. These two fields allow good diagnostic of the connection's bandwidth on IP. For RTCP support and diagnostics, each time a packet is transmitted, the first 12 bytes of the packet payload (in the case of HDLC/CPU packets), or the first 12 bytes of RTP header for PCM packets, are copied into external memory. For HDLC/CPU channel carrying RTP, the first 12 bytes will represent the mandatory fields of the RTP
70 Zarlink Semiconductor Inc.
Data Sheet
MT92210
header. With this information, RTCP packets can be generated without requiring communication between the host on which the MT92210 is running and the source of the HDLC data stream.
7.3.9
RTD
The RTD field (RouTing Destination) indicates where this packet will be destined in the network interface. In most applications it will be set to transmit packets to port A, but the field allows flexibility by allowing the possibility of internal loopback, sending to port B, or other destinations.
The format of the basic TX RTP connection structure is the following:
b15 b14 b13 b12 b11 b10 b9 +0 +2 +4 +6 +8 +A +C +E +10 +12 +14 +16 +18 +1A +1C +1E +20 +22 +24 +26 Time Stamp Offset [31:16] Time Stamp Offset [15:0] Transmitted Packet Count [15:0] Sequence Number [15:0] Transmitted Octet Count [31:16] Transmitted Octet Count [15:0] First Word of Last RTP Packet Sent Second Word of Last RTP Packet Sent Third Word of Last RTP Packet Sent Fourth Word of Last RTP Packet Sent Fifth Word of Last RTP Packet Sent Sixth Word of Last RTP Packet Sent TX RTP Header Structure Pointer [20:5] SI b8 b7 b6 b5 b4 b3 b2 b1 b0
Figure 38 - TX RTP Connection Structure
Zarlink Semiconductor Inc.
71
MT92210
Field
TX RTP Header Structure Pointer
Data Sheet
Description
Pointer to TX Header assembly structure. This pointer points to increments of 32 bytes. All packet headers are formed based on the TX Header assembly structure. If changes in the headers must be made dynamically during a connection, this field may be rewritten atomically by software in order to point to another TX Header Structure. Sequence Number Insert. When `0', the Sequence number is taken directly from the HDLC / TXCPU packet. When `1', the sequence number is always inserted by this structure and the one in the original packet is ignored. This field must always be set if an xxPCM channel addition is opened over of this connection structure. This number is added to the RTP time stamp of xxPCM / HDLC / TXCPU packets as they are sent. It is used to randomize the starting point of the RTP time stamp. Free-running counter of all packets transmitted on this connection. Sequence Number that will be sent in the next RTP packet if the SI bit is set. This field should be initialized to a random value by software. A Free-running counter of the total number of transmitted bytes in all packets including all header bytes. Record of first 6 words of last transmitted RTP payload. These fields can be used to monitor what is being sent on this connection. This structure must begin on a 64-byte boundary.
SI
Time Stamp Offset Transmitted Packet Count Sequence Number Transmitted Octet Count Word of Last RTP Packet Sent Note
Table 25 - Fields and Description
72
Zarlink Semiconductor Inc.
Data Sheet
MT92210
If an xxPCM channel is carried by this connection, then the format of the TX RTP connection structure will be the following:
b15 b14 b13 b12 b11 b10 b9 +0 +2 +4 +6 +8 +A +C +E +10 +12 +14 +16 +18 +1A +1C +1E +20 +22 +24 +26 +28 +2A Samples per packet at 40 kbps Samples per packet at 24 kbps I Buf Size
b8
b7
b6
b5
b4
b3
b2
b1
b0
Next Packet Assembled Starting With This Byte [13:0] V Extra Delay Frames [7:0]
TX Silence Suppression Structure Base [20:5] TX RTP Header Structure Pointer [20:5] Samples per packet at 64 kbps SI Number of Channels [7:0] Samples per packet at 32 kbps Samples per packet at 16 kbps
Time Stamp Offset [31:16] Time Stamp Offset [15:0] Transmitted Packet Count [15:0] Sequence Number [15:0] Transmitted Octet Count [31:16] Transmitted Octet Count [15:0] First Word of Last RTP Packet Sent Second Word of Last RTP Packet Sent Third Word of Last RTP Packet Sent Fourth Word of Last RTP Packet Sent Fifth Word of Last RTP Packet Sent Sixth Word of Last RTP Packet Sent Bearer 1 - Circular Buffer Base Address [20:9] Bearer 2 - Circular Buffer Base Address [20:9]
Bearer N-2 - Circular Buffer Base Address [20:9] Bearer N-1 - Circular Buffer Base Address [20:9]
Figure 39 - xxPCM Channel Addition to TX RTP Connection Structure
Zarlink Semiconductor Inc.
73
MT92210
Field
I
Data Sheet
Definition
Init bit. This field is cleared by software upon initialization of an xxPCM channel addition to a TX RTP connection. It is then set by hardware when an "Assembly Event - Service xxPCM RTP Channel" is received having the ST bit set. Packets are only sent when this bit is read at `1' from the xxPCM Channel addition to TX RTP Connection Structure. When the I bit is cleared, this field contains the number of frames in the first virtual xxPCM that will be sent when the I bit is first set by hardware. When the first "Assembly Event - Service xxPCM RTP Channel" with ST bit set is received, no packet is sent out, but this field is initialized to its value plus the current TX TDM Circular Buffer Write pointer. In this way, the first packet to be sent out can be timed to only contain valid voice samples, since this feature enables the software to "drop" the N first packets. Setting this field to zero initially will force the hardware to start sending data one packet transmission period after setting the I bit. After the initialization of the xxPCM channel, this field is used to remember which is the oldest not yet sent byte in the TX xxPCM Circular Buffers associated with this xxPCM channel. TX xxPCM Circular Buffer Size. "000" = 256 samples (512 bytes); "001" = 512 samples (1024 bytes); others = reserved. Valid bit. When `0', all "Assembly Event - Service xxPCM RTP Channel" will be ignored, preventing xxPCM channel packets from being sent. This field is reserved for future use and should always be set zero. Pointer to a TX Silence Suppression structure. A value of 0000h indicates no silence suppression is needed on this xxPCM channel. The pointer points to 32 byte increments in SSRAM A. Number of TDM bearers (i.e. TX xxPCM Circular Buffers) to be included in a packet. This field is usually set to 1. It specifies the number of TX xxPCM Circular Buffers that will be read for each frame that is sent, extracting a sample from each of them. This field also defined the number of "Bearer x - Circular Buffer Base Address" extension words appended to this structure. Number of samples to assembled into a single packet at a given CODEC rate. The total number of samples in packet is calculated as such: "Number of Bearers" * "Samples per packet". Pointer to each TX xxPCM circular buffer that must be read in order to assemble a packet. There must be one of these addresses per Bearer in the xxPCM channel. This points to circular buffers in increments of 512 byte of addressing in SSRAM A. For each bearer in this xxPCM channel, a single circular buffer base address must be specified in one of these extension words. All xxPCM channels will have between 1 and 255 bearers, thus between 1 and 255 extension words.
Next Packet Assembled Starting With This Byte
Buf Size V Extra Delay Frames TX Silence Suppression Structure Base Number of Bearers
Samples per packet at x Kbps Bearer X - Circular Buffer Base Address Bearers
Table 26 - Fields and Description
74
Zarlink Semiconductor Inc.
Data Sheet
The format of the TX RTP header structure is the following:
b15 b14 b13 b12 b11 b10 b9 +0 IPv6 IDE +2 +4 +6 +8 +A +C b8 b7 b6 b5 b4 b3 b2 b1 b0
MT92210
Identification Counter Source Address [15:2] RTD
Packet Type
Header Length [9:2] Link Header Length [7:0] 802.3 Length Position [7:0]
UDP Header Start [9:2] Minimum Total Packet Length [7:0] 8P 802.3 Length Adjust [6:0] ID v6 Position [9:2] Header Word 0
Header Word N-1
Figure 40 - TX RTP Header Structure
Field
IPv6 IDE
Description
This bit must set when the IP version for this connection is 6. Identification Enable. When `1' the identification dword will be written in the packet. When `0', the identification dword will be set to an undefined value if it is present in the headers. IDE should be set when an IPv4 header is present or when an IPv6 fragmentation header is present. Points to a 4-byte field in the lower 64K of SSRAM A which will be read as the identification field that is to be inserted in the packet. When the IDE bit is set, this 32-bit counter will be incremented and written back to memory. In IPv4 only, the bottom 16 bits of this 32-bit identification counter will be written in the IPv4 header. This field is ignored when the IDE field is zero. Routing Destination. This field indicates when packet generated with this header structure should be set. Multicast destinations are supported through an ORed combination of the following individual destinations. However, when packets are sent to the Packet Identifier, they cannot be sent anywhere else. "000000000" = Delete; "1xxxxxxxx" = reserved; "x1xxxxxxx" = TX Link A HP; "xx1xxxxxx" = TX Link A LP; "xxx1xxxxx" = TX Link B LP; "xxxx1xxxx" = TX Link B HP; "xxxxx1xxx" = reserved; "xxxxxx1xx" = Network CPU Packet Buffer; "xxxxxxx1x" = reserved; "000000001" = Packet Identifier.
Identification Counter Source Address
RTD
Table 27 - Fields and Description
Zarlink Semiconductor Inc.
75
MT92210
Field
Packet Type
Data Sheet
Description
This field indicates the type of the first header present in the packet. This field is only used when the RTD is set to sent packets to the packet identifier. "0000" = LLC Header; "0001" = PPP Header; "0010" = IP Header; "0011" = MPLS Unicast Header; "0100" = MPLS Multicast Header; "0101" = MPOA Tag; "0110" = LANEv1-Ethernet/802.3 Header; "0111" = UDP payload (with or without RTP contained in payload); others = reserved. Points to the first dword of the UDP header, relative to header word 0. Header length in dwords, includes all Header Words. Minimum desired packet length including headers+48, in bytes. Hardware will pad the payload with 0's up to this length as required, e.g. if a minimum Ethernet encapsulated packet of 46 bytes is desired, and the Link Header is 14 Bytes, this value should be set to 46+14+48=108. When no minimum packet length is desired, this field should be set to 0. This field is the byte counter of all Header words, less the initial padding bytes if there were any. 802.3 Present. When `1', an 802.3 header requiring a Length is present. This value is subtracted from hardware calculated packet length to obtain correct 802.3 length. The hardware calculated packet length = Payload + Header Words - Padding. Position in bytes of the first byte of the 802.3 Ethertype/Length with respect to Header word 0. Points to the dword of the IPv6 header, relative to Header Word 0, in which the packet identification field will be written.
UDP Header Start Header Length Minimum Total Packet Length
Link Header Length 8P 802.3 Length Adjust
802.3 Length Position ID v6 Position
Table 27 - Fields and Description (continued)
7.4
PCM Packets
In the case of an connection carrying PCM or ADPCM, the packet assembly module uses the TX connection structure to determine how the bytes should be assembled, as well as all the different headers needed by the multiple protocols (Link, IP, UDP, RTP). The two fields that will determine the shape and size of the packet payload are the Total number of frames, that determines how many payload samples per channel will be carried by the packet, and the Number of Bearers, which tells how many xxPCM bearers will be included in the packet. The total amount of payload samples in the packet will be Total number of frames multiplied by Number of Bearers. This is converted into bytes according to the compression rate.
7.4.1
Next TDM Write Pointer
The first word of the structure contains the Next TDM write pointer on which the next packet can be assembled. This is used when receiving a packet assembly event from the queue to determine if the packet assembly requested is valid or not. If the current TDM pointer is greater or equal to this value, then the event is valid; otherwise, it is ignored. The Initialized bit is used to detect the start-up of the connection: when a packet assembly event is read and the Initialized bit is '0', the first packet will be discarded, and the Next TDM write pointer will be initialized to the current TDM pointer + Next TDM write pointer. This means that this field should be initialized as an
76
Zarlink Semiconductor Inc.
Data Sheet
MT92210
offset that says: "the first packet should be assembled this many frames after the first event is read". It allows a start-up delay on the connection.
7.4.2
Valid Bit
The Valid bit is used to ensure that no corrupt structures will be read while the scheduler is being programmed. While this bit is '0', any event that is read will simply be ignored (i.e. it will not even set the Initialized bit). The order of events should be the following: program the assembly structure (with Valid = '0'), then program the scheduler events, and finally set the Valid bit to '1'.
7.4.3
Buffer Size
The Buffer Size field indicates how large the TX Circular buffer containing the data is, from a minimum of 512 bytes up to a possible 4K bytes. The compression rate is determined implicitly from the data in the circular buffer: when it writes to the circular buffer, the TX TDM also uses auxiliary information to indicate the compression rate of the data in the buffer. The packet will then be assembled according to this compression rate. Note that a scheduling mechanism must be used to ensure that all data contained within a single packet is coded in the same compression format. This is discussed in further detail in the TX TDM section. Note that the Total number of frames keeps its definition regardless of the compression rate, so with ADPCM 16 kbps, 4 frames of data only come out to 1 byte. The assembly process can generate one of 6 payload types for xxPCM packets: one for PCM, one for each ADPCM compression rate, and one for CN packets. In the TX RTP header structure, the payload types are written in the RTP header.
7.4.4
TX Silence Suppression Structure Base
The TX Silence Suppression Structure Base points to a structure that will be used to perform silence suppression on the xxPCM channel carried over this connection. When its value is 0000h, it means that no silence suppression will be done on this channel. Silence suppression cannot be used on channels carrying more than 1 bearer.
7.4.5
Extra Delay Frames
The Extra Delay Frames are also related to the silence suppression calculations: they indicate that the packet assembly should not use the most recent xxPCM data to assemble its packet, but instead should back up by a certain number of frames. This allows the silence suppression calculations on a block to be performed fully before the data is sent in an IP packet, ensuring, for example, that there is no start-up delay between the moment that voice begins again and the moment that packets start being sent again.
7.4.6
RTP Timestamp
The RTP timestamp sent in PCM packets is calculated in the following way: global timestamp corresponding to the first byte in the packet + Timestamp Offset written in the structure. The global timestamp is fed to the assembly module by the TX TDM and can either be a free-running counter within the chip or a value extracted from 4 time-slots on the TDM bus. See the TX TDM section for more information on sourcing the timestamp.
7.4.7
Circular Buffer Base Addresses
Finally, at the very end of the structure, are a certain number of Circular Buffer Base Addresses that indicate, for each channel in the connection, where is the circular buffer associated to it. These addresses point to 512 byte boundaries, which is the minimum size for any circular buffer, since the xxPCM data is only contained in the left byte of the circular buffer. The buffers may be larger, in which case the lower bits of the base address will not be used: the Buffer Size field indicates the size for all the circular buffers used by this connection.
7.5
HDLC Packets
HDLC and CPU-sourced packets are not payload-formatted by the TX connection structure. They are simply packaged in the link, IP and UDP (or null) headers and transmitted as such. The assembly process, in addition to encapsulating the payload in these protocols, may perform some RTP functions. The Sequence Number Insert bit indicates whether the RTP sequence number should be generated by the structure or kept as it is in the payload.
Zarlink Semiconductor Inc. 77
MT92210
Data Sheet
The Timestamp Insert bit, which comes from the event queue and originated in the TX TDM for HDLC packets (or was written in the descriptor by the CPU), indicates whether the timestamp from the packet should be used, or if it should be added to the global chip timestamp before being sent. To ensure that the timestamp passes through without any modifications set the Timestamp Insert bit to '0' and the Timestamp Offset to 0h as well. By setting the Sequence Number Insert bit to '0' and making the timestamp transparent as described above, non-RTP packets can also be sent through HDLC or the CPU port.
78
Zarlink Semiconductor Inc.
Data Sheet
7.6 Silence Suppression
MT92210
The other operation that the packet assembly module can perform is calculating silence suppression information on data contained in circular buffers. The objective is simple: after performing calculations on a block of PCM data (using the PCM bytes), the calculator must decide if the channel currently being treated is silent or not. It then communicates this information to the packet assembler that will discard all RTP packets containing that channel until the channel re-enables. Silence suppression calculations are performed on the block of data that is about to be sent in the xxPCM packet by the assembly process. By synchronizing the two events, the assembly process will have the most up-to-date information concerning the suppression of its packets and voice quality will be maintained to a maximum. The silence suppression process reads its data from the same circular buffer as the packet assembly; the minimum size for any TX circular buffer is 512 bytes, because silence suppression information is only contained in the lower byte of each word in the buffer (thus the minimum amount of useful data in a circular buffer is 256 bytes). There are 2 sequential steps to be performed in the silence suppression calculation. The first is the filtering of the input signal. In some cases, PCM signals are not centered around 0 and have a constant offset that is added to them: performing energy calculations with these offset values would lead to erroneous results and poor performance. Thus, to eliminate this error, the silence suppression module uses a first-order high-pass butterworth filter with a cutoff frequency of 10 Hz to eliminate DC and extremely low-frequency signals. The butterworth filter keeps the entire context it needs in the Local Butterworth HP 10 Hz Context field. This filter can be enabled or disabled by using the Local Butterworth enable bit. To filter the signal, it must first be expanded into linear form. The Local Law bit indicates if the input signal is coded using u-law or A-law. Using the correct law, each PCM input sample is expanded into its linear value. Once the filtering of the input signal has been calculated, silence suppression can be correctly performed on the data. The silence suppression process uses an adaptive algorithm to determine whether the input signal represents silence or voice. The basic approach used in the silence suppression algorithm is to smooth out the level of the signal to remove any frequency-dependent components, then to establish the minimum level at which the signal maintains itself over a reasonable period of time. Then, the current level of the signal is compared to the floor level, and if it is measured to be larger, then the signal is deemed to be voice; otherwise it is considered to be silence. If the packet is silent, then a CN packet may potentially be generated. If the last packet was not suppressed, then a CN packet will definitely be transmitted. A CN packet will also be sent at other points in time when the padding energy at the remote end needs to be updated. The Last Suppress bit indicates the state of the last packet, which allows a CN packet transmission decision to be taken. The CN energy is calculated by summing the energies of the most recent samples received. Depending on whether the current state is voice or silence, the energy will be summed on a different number of samples, using the First Energy Period and Subsequent Energy Period respectively. This is done because energy on background noise and silence can be calculated on a much longer period to obtain greater accuracy. The sum of samples is kept in the Energy Sum and the sample count is kept in the Energy Counter. When the Energy Counter reaches the terminal count, a linear-to-dB conversion is performed to take the Energy sum divided by the Energy Counter to obtain the average linear energy, then converted to a logarithmic scale to obtain an energy in dBov. The TX Silence Suppression Structure contains a dB Correction that allows the dB energy to be converted to any scale, like dBm0 instead of dBov, for example. There is also a Maximum dB Value and a Minimum dB Value that can be set, making sure that the value in CN packets stays within a certain range. The silence suppression information can also be fed to the process externally. When this is the case, a special PCM code is used on the TDM bus. In this mode, 2 TSSTs must be used to feed the MT92210 with the transmit data. When the last PCM byte of the packet is read off the H.110 bus is 00h and the associated time slot upper bit also indicates 0, this means that the packet must be suppressed. Note that the TX unsigned PCM magnitude is transmitted on the lower 7 bits of the associated time slot. If the code received is normal data (upper bit 1), then the packet is valid. In this case, the external agent makes all the suppress/don't suppress decisions, but the MT92210 still calculates the CN Energy and decides when to send and when not to send CN packets. The MT92210 also supports many modes in which it can send CN packets. In the most common configuration, it will suppress silence packets and send CN packets at the beginning of silence periods, or whenever it decides to update. It is also possible to configure it to suppress silence packets but never to send CN packets at any time. It also supports two modes in which it does not suppress packets. In the first one, it uses the marker bit in RTP to
Zarlink Semiconductor Inc.
79
MT92210
Data Sheet
indicate the beginning of a voice period; in the second, all silence packets are indicated with a marker bit = `1', as well as the first packet at the beginning of a voice period. Finally, instead of calculating its own CN energy and generating the packet itself, the MT92210 can use a preprogrammed CN packet. This preprogrammed packet can be of variable length, allowing spectral data to be passed along as well as an energy value. Preprogrammed packets must be written into external SSRAM A by an agent through the CPU interface and may be updated periodically. Because a pointer is given to the preprogrammed packet, its payload may be changed in a glitch-free, atomic way. Spectral CN packets may be up to 64 bytes in length. The silence suppression process also monitors and counts underruns that occur on the RX TDM side. The underrun information from the RX side is passed along and is written to the TX circular buffer. The silence suppression process can thus keep a 16-bit Underrun Count of the number of underrun events that have occurred. The format of the TX Silence Suppression Structure varies according to whether or not the silence suppression decision is being taken internally or if it is being fed from an outside agent, and according to whether or not the generated CN packet will be a white energy value or a preprogrammed spectral value.
80
Zarlink Semiconductor Inc.
Data Sheet
The possible formats for this structure follow:
b15 b14 b13 b12 b11 b10 b9 +0 +2 +4 +6 +8 +A +C +E +10 +12 +14 +16 +18 +1A +1C +1E +20 +22 +24 +26 +28 +2A +2C +2E +30 +32 +34 +36 +38 ratio_while_silent [7:0] floor_exp_start_v CTS ceiling_exp [4:0] dB Correction [7:0] Minimum dB Value [6:0] b8 b7 b6 b5 b4 b3 b2 b1 b0
MT92210
Maximum dB Value [6:0] Type HP 10Hz Context [28:16] 0 HPE BL
HP 10Hz Context [15:0] floor_exp [4:0] holdover_counter [5:0]
holdover_talk_counter [6:0]
floor_latch [12:0] ceiling_latch [12:0] LS amp_iir [15:0] ceiling_exp_half_life_counter [15:0] floor_exp_half_life_counter [15:0] Latched Energy [6:0] Energy Sum [31:16] Energy Sum [15:0] Energy Counter [12:0] Underrun Count [15:0] Energy Decrease Threshold [7:0] amp_iir_rise_length amp_iir_fall_length Energy Increase Threshold [7:0] holdover_time [6:0] Energy Sum [38:32] amp_iir [21:16]
ceiling_exp_half_life [15:0] floor_exp_half_life [15:0] ceiling_exp_start_v max_floor_level [12:0] min_threshold_while_talking [12:0] min_threshold_while_silent [12:0] flux_min_threshold [12:0] ratio_while_talking [7:0] First Energy Period [12:0] Subsequent Energy Period [12:0] flux_ratio [4:0]
Figure 41 - TX Silence Suppression Structure: Internal VAD & White Energy Estimation
Zarlink Semiconductor Inc.
81
MT92210
b15 b14 b13 b12 b11 b10 b9 +0 +2 +4 +6 +8 +A +C +E +10 +12 +14 +16 +18 +1A +1C +1E +20 +22 +24 +26 +28 +2A +2C +2E +30 +32 +34 +36 +38 ratio_while_silent [7:0] floor_exp_start_v amp_iir_rise_length amp_iir_fall_length holdover_time [6:0] Underrun Count Preprog Packet Length - 1 Preprogrammed Packet Pointer[16:2] Preprog Pnt [20:17] CTS ceiling_exp [4:0] Type HP 10Hz Context [28:16] HP 10Hz Context [15:0] floor_exp [4:0] holdover_counter [5:0] 0 HPE BL b8 b7 b6 b5 b4 b3 b2 b1 b0
Data Sheet
holdover_talk_counter [6:0]
floor_latch [12:0] ceiling_latch [12:0] LS amp_iir [15:0] ceiling_exp_half_life_counter [15:0] floor_exp_half_life_counter [15:0] amp_iir [21:16]
ceiling_exp_half_life [15:0] floor_exp_half_life [15:0] ceiling_exp_start_v max_floor_level [12:0] min_threshold_while_talking [12:0] min_threshold_while_silent [12:0] flux_min_threshold [12:0] ratio_while_talking [7:0] flux_ratio [4:0]
Figure 42 - TX Silence Suppression Structure: Internal VAD & Spectral Energy Forwarding
82
Zarlink Semiconductor Inc.
Data Sheet
b15 b14 b13 b12 b11 b10 b9 +0 +2 +4 +6 +8 +A +C +E +10 +12 +14 +16 +18 +1A +1C +1E +20 +22 +24 +26 +28 +2A +2C +2E +30 +32 +34 +36 +38 First Energy Period [12:0] Subsequent Energy Period [12:0] Latched Energy Energy Sum [31:16] Energy Sum [15:0] Energy Counter [12:0] Underrun Count Energy Decrease Threshold Energy Increase Threshold Energy Sum [38:32] dB Correction [7:0] Minimum dB Value [6:0] b8 b7 b6 b5 b4 b3 b2 b1 b0
MT92210
Maximum dB Value [6:0] Type 1
Figure 43 - TX Silence Suppression Structure: External VAD & White Energy Estimation
Zarlink Semiconductor Inc.
83
MT92210
b15 b14 b13 b12 b11 b10 b9 +0 +2 +4 +6 +8 +A +C +E +10 +12 +14 +16 +18 +1A +1C +1E +20 +22 +24 +26 +28 +2A +2C +2E +30 +32 +34 +36 +38 Underrun Count Preprog Packet Length - 1 Preprogrammed Packet Pointer [16:2] Preprog Pnt [20:17] Type 1 b8 b7 b6 b5 b4 b3 b2 b1 b0
Data Sheet
Figure 44 - TX Silence Suppression Structure: External VAD & Spectral Energy Forwarding
84
Zarlink Semiconductor Inc.
Data Sheet
Field
dB Correction
MT92210
Description
Two's complement signed number. Added to the dB energy before going to the Min/Max value masks. When this field is worth +1, an energy of -65 dBov will be converted to an energy of -66 dBov. Note: The dB Correction is applied first; the Maximum/Minimum dB Value range verification is applied next (and truncation may be done to force the value within the range); and the Decrease/Increase Threshold calculation is performed last. The maximum dB value is the highest energy dB value that can be generated. Generally set to either 0 or 30. The minimum dB value is the lowest energy dB value that can be generated. Generally set to either 127 or 78. How to send comfort noise packets. "000" = do not sent comfort noise packets; "001" = send internally calculated white spectrum energy comfort noise packets; "010" = send preprogrammed comfort noise packets; "011" = send no comfort noise packets (send all voice packets regardless), but set marker bit at beginning of voice period, "100" = send no comfort noise packets (send all voice packets regardless), and set marker bit in all silent packets and at beginning of voice period; others = reserved. High Pass Filter Enable. When `1', a 10 Hz High Pass filter will be applied to the input signal before going through the VAD process and the energy estimation process. If the high pass filter is not done internally, it must have been done externally to achieve proper energy matching. Circular Buffer Law. `0' = samples in TX Circular Buffer are in u-law; `1' = samples in TX Circular Buffer are in A-law. Context of the high pass filter. Must be initialized to zero. Should be initialized to zero by software. Should be initialized to zero by software. Should be initialized to zero by software. Should be initialized to zero by software. Should be initialized to zero by software. Should be initialized to zero by software. Should be initialized to zero by software. Last packet Suppressed. When `1', the last packet was suppressed. Current talk status. When `0', the VAD is currently suppressing. When `1', the VAD is not suppressing. Should be initialized to zero by software. Should be initialized to zero by software. Last sent energy level exactly as it was sent in the comfort noise description packet. Accumulator used to estimate the idle line energy level. Must be initialized to zero by software.
Maximum dB Value Minimum dB Value Type
HPE
BL HP 10Hz Context ceiling_exp floor_exp holdover_talk_counter holdover_counter floor_latch ceiling_latch amp_iir LS CTS ceiling_exp_half_life_counter floor_exp_half_life_counter Latched Energy Energy Sum
Table 28 - Fields and Description
Zarlink Semiconductor Inc.
85
MT92210
Field
Energy Counter
Data Sheet
Description
Counter used to frame energy estimation period. This counter starts off at zero and counts up to either First Energy Period or Subsequent Energy Period. When it reaches it terminal counter, the comfort noise level is updated internally and may be resent. This field is reset to zero when the VAD identifies a packet as being non-silent. This field must be initialized to 0 by software. Free-running 16-bit underrun counter. This counter monitors underruns that occur on the TSST adjacent to the TSST that is being silence suppressed. When the AS bit is cleared, TSST0 & TSST1 are associated. When the AS bit is set, TSST0 & TSST2 are associated. Number of dB of difference (vs the last sent comfort noise packet) required to do retransmission of a new (updated) comfort noise packet. 00h is illegal; 01h means retransmit on any difference; 02h means retransmit on a 2 dB difference; writing this value to 128 will prevent all retransmission. Should be initialized to 3 by software. Should be initialized to 7 by software. Should be initialized to 16 by software. Should be initialized to 300 by software. Should be initialized to 2716 by software. Should be initialized to 17 by software. Should be initialized to 17 by software. Should be initialized to 8 by software. Should be initialized to 4000 by software. Should be initialized to 8 by software. Should be initialized to 32 by software. Should be initialized to 32 by software. Should be initialized to 57 by software. Should be initialized to 32 by software. Number of frames that will be averaged out to produce the estimation of the comfort noise energy when silence is first detected. Number of frames that will be averaged out to produce the estimation of the comfort noise energy for comfort noise refresh packets. Length of the preprogrammed comfort noise packet in bytes (minus 1). To send single byte comfort noise packets (the basic non-spectral mode), this field must be set to 00h. This field points to the location in SSRAM A at which the preprogrammed packet is located.
Underrun Count
Energy Decrease/Increase Threshold
amp_iir_rise_length amp_iir_fall_length holdover_time ceiling_exp_half_life floor_exp_half_life ceiling_exp_start_v floor_exp_start_v flux_ratio max_floor_level min_threshold_while_talking min_threshold_while_silent flux_min_threshold ratio_while_silent ratio_while_talking First Energy Period Subsequent Energy Period Preprog Packet Length - 1
Preprogrammed Packet Pointer
Table 28 - Fields and Description (continued)
86
Zarlink Semiconductor Inc.
Data Sheet
8.0 Packet Disassembly
MT92210
After packets have gone through the look-up process on the reception side, they can be routed to the packet disassembly module, which will transform RTP packets into PCM bytes, ADPCM samples, or HDLC/CPU-destined packets. The packet disassembly is not responsible for any header verification except for RTP headers (this is done in the network module) but it performs PDV monitoring to diagnose and reduce delay, packet loss compensation (for connections using RTP) and some RTCP functions in hardware. The module logs all of its errors and events into the RX disassembly Event Report Queue. This queue contains structures that may be generated by RTP connections, xxPCM channels, HDLC channels and CPU channels. Each event type has its own status bits and errors that may be flagged. The Event Report queue is contained in SSRAM B and is of a variable size between 256 events (4K bytes) and 32K events (512K bytes). The format of the RX disassembly Event Report Queue is the following:
+0 +10
Event 0 Event 1
+(N-2)*10h +(N-1)*10h
Event N-2 Event N-1
Figure 45 - RX Disassembly Event Report Queue
The RX Disassembly Event Report Queue is a circular buffer in SSRAM B used to report disassembly events to the host processor. It can be programmed to sizes of 4K bytes to 512K bytes in steps of 2^k. It must be mapped on a base address of its size. The position and size of this queue can be programmed at register address 0x720.
8.1
RTP Treatment
The disassembly module performs a 2-step process when treating received RTP packets: the first portion is performing all UDP/RTP de-encapsulation. The packet may be discarded if the UDP checksum is incorrect, depending on the polarity of the UDP Checksum Discard bit. Next, if RTP is present, the RTP version is checked and the packet is discarded if it is not equal to 2. Finally, the RTP headers are parsed if they are present and the packet is discarded if the headers extend beyond the end of the packet (i.e. the length of the packet and the info indicated in the headers cannot concord). If a packet passes all of these tests, then the general RTP functions are performed. The packet is sent to an RX RTP Connection Structure; firstly, the packet's Payload Type and Marker bit are used to index in a Payload Type /Marker Bit Table, to determine what is the type of the received packet. Note that in RTP, payload types are often determined dynamically, and thus one table per connection might be required. Packets received by the disassembly module may be tagged as xxPCM, HDLC or CPU packets, all depending on their payload type and marker bit. The information associated to the extension address also indicates, for xxPCM packets, what type of compression rate the packet is coded at (PCM, ADPCM 40, 32, 24, 16, or CN packet), as well as whether law translation should take place. For some combinations of payload type and marker bit, the table indicates that a report structure should be generated for this packet; this structure will report the payload type and marker bit in it. The table also indicates, for each payload type in RTP, if it should be included in the Network Jitter calculations (described in greater detail below), and which RX RTP Channel Structure Address it should use. Each disassembly structure can point to up to 16 RX RTP Channel Structure Addresses, and each of these can route packets to a different destination. Since a single connection will usually only carry a single voice channel (or aggregation of channels), this can use up to 6 extension structures (1 per voice coding rate), leaving 9 extension structures to route various associated signaling or control payload types to other extension structures (which can then send them to control agents like the CPU, or on the HDLC bus).
Zarlink Semiconductor Inc. 87
MT92210
Data Sheet
The table is pointed to by the Payload Type/Marker Bit Table Base field in the structure. Since the payload type and marker bit are, together, 8 bits, there are 256 entries in a table. Conversely, in UDP-only connections, the UDP payload length is used to point in this structure. Since the pointer is only 8 bits, the UDP length will be capped, and the value 255 will be used if the payload length is greater than 255. RTP Sequence number checking is also performed on each packet received by the structure. When a new packet arrives its sequence number is compared to the Last Received Sequence Number, and if they do not follow each other sequentially, a sequence number error will be reported and an error structure containing both sequence numbers will be reported. If the LR (Loss Report) bit is set, the module will report any packet loss by generating an error report structure that will contain both the previous and current sequence number. Then, the Network Jitter may be calculated. The Network Jitter is a measure of how much the inter-arrival delay between 2 packets varies on average. When each packet is received, the module calculates the difference between its current time stamp and the Last Received Timestamp, as well as the difference in actual arrival time in the chip using the current local timestamp and the Last Local Timestamp. Once it calculates this inter-arrival delay, it adds it to the previous network jitter using the function J = J*(15/16) + D*(1/16), where J is the old sum and D is the new value. When the software wishes to generate an RTCP packet, it can consult this value and insert it in the inter arrival jitter field of the RTCP packet. Note that packets will only be included in the Network Jitter if, after looking them up in the treatment table, their Include Jitter bit is '1'. If this bit is '0', then the Network Jitter will not be updated and the Last Received Timestamp and Last Local Timestamp will not be modified. In other words, from a network jitter standpoint, it will be as if the packet never arrived. All valid packets will also be included in the structure's 16-bit Received Packet count and 32-bit Received Octet Count. These are used to monitor the size and frequency of packets that are received. In the case of the octet count, it helps to see what is the average size of the packets being received. The RX Channel structures will also have their own counters. When packets are looked-up in the table, the result will give an RX Channel Structure Number as well as the type of the RX Channel Structure. The RX Channel Structure Number is then used to select the correct RX Channel Structure Address from the RX connection structure and the RX Channel structure is read. This structure may be in the xxPCM, HDLC or CPU format. If the Type field in the RX Connection Structure associated to the RX Channel Structure is delete, then no RX Channel structure will be read and the packet will be deleted. Otherwise, the RX Channel structure is read and interpreted according to its type.
88
Zarlink Semiconductor Inc.
Data Sheet
The format of the RX RTP Connection structure is the following:
MT92210
b 15 b14 b13 b12 b11 b10 b9 +0 +2 +4 +6 +8 +A +C +E +10 +12 +14 +16 +18 +1A IJ R Type UCD
b8
b7
b6
b5
b4
b3
b2
b1 b0
Payload Type / Marker Bit Table Base [20:7] RTP UCR LR Last Received Sequence Number [15:0] Last Received Time Stamp [31:16] Last Received Time Stamp [15:0] Last Local Time Stamp [23:8] Last Local Time Stamp [7:0] Network Jitter Integer [11:0] Received Packet Count [15:0] Received Octet Count [31:16] Received Octet Count [15:0] Network Jitter Integer [19:12] Net Jitter Fraction [3:0] JI I
PCM Info
RX RTP Channel 0 Structure Address [20:5]
IJ
R
Type RX RTP Channel 15 Structure Address [20:5]
PCM Info
Figure 46 - RX RTP Connection Structure Field
Payload Type / Marker Bit Table Base UCD
Description
This field is a pointer to a Payload Type / Marker Bit Table Structure and is used to determine the index used in the 16-way split to a RX RTP Channel Structure. This pointer is defined in increments of 128 bytes. UDP Checksum Error Discard. When this bit is `1' and a packet is received with an invalid UDP checksum, the packet will be discarded prior to updating the content of this structure. This bit must be set when packets received through this RX RTP Connection Structure are in the RTP format. This bit must be cleared when packets are non-RTP (i.e., any other protocol over UDP). The indexing to the Payload Type / Marker Bit table will be done with the Payload Type / Marker Bit for RTP, and will be done with the UDP Payload Length for all other protocols over UDP.
RTP
Table 29 - Fields and Description
Zarlink Semiconductor Inc.
89
MT92210
Field
UCR
Data Sheet
Description
UDP Checksum Error Report. When this bit is `1', any packet received with an erroneous UDP checksum will generate an event in the RX Disassembly Event Report Queue. Loss Report. When this bit is set and two consecutive packets do not have sequential RTP sequence numbers, an event in the RX Disassembly Event Report Queue will be generated. This bit should be cleared if packets processed by this structure are not in the RTP format. Jitter init. This bit must be cleared by software when this structure is first created. It will be set by hardware when the first packet is received that has the IJ bit set in the RX RTP Channel Structure branching entry. Initialized bit. This bit must be cleared by software when this structure is first created. It will be set by hardware when the first packet is received. Sequence number contained in the last received RTP packet. This field is not defined if packets processed by this structure are not in the RTP format. Time Stamp contained in the last received RTP packet. This field is not defined if packets processed by this structure are not in the RTP format. This field contains the local TDM Bus Time Stamp at the arrival time of the last packet processed by this structure. Only the bottom 24 bits of the local TDM Bus Time Stamp are kept. This field is used to calculate the RTP interpacket jitter. This field contains the interpacket jitter as monitored for all packets received via this structure, as defined by the RTP specification. The time unit of this field is frames. This field is a counter of the total number of packets received on this connection so far. This field is a counter of the total number of bytes received on this connection so far. For each packet received, this field will increment by UDP Length - 8. Include Jitter. When this bit is set, the RTP Time Stamp and Sequence Number of any packet that passes through this RX RTP Channel Entry Split will be used to update the following fields: Last Received Sequence Number, Last Received Time Stamp, Network Jitter Integer and Fraction. Report UUI/LI Combination to CPU through the RX Disassembly Event Report Queue (when set). Type of RX RTP Channel Structure. "000" = PCM + ADPCM; "001" = HDLC; "010" = RX CPU; "111" = delete; others = reserved.
LR
JI
I Last Received Sequence Number Last Received Time Stamp Last Local Time Stamp Network Jitter Integer/Fraction Received Packet Count Received Octet Count IJ
R Type
Table 29 - Fields and Description (continued)
90
Zarlink Semiconductor Inc.
Data Sheet
Field
xxPCM Info
MT92210
Description
This field contains additional information about PCM and ADPCM connection packets. It is used to distinguish PCM and ADPCM encoding as well as CN packet. "0000" = PCM 64 kbps (no law change); "0001" = ADPCM 40 kbps; "0010" = ADPCM 32 kbps; "0011" = ADPCM 24 kbps; "0100" = ADPCM 16; kbps; "0101" = CN Packet (one byte, white, internal); "1000" = PCM 64 kbps (u-law -> A-law); "1001" = PCM 64 kbps (A-law -> u-law); "1010" = PCM 64 kbps (A-law -> u-law (except 00h)); "1011" = PCM 64 kbps (u-law -> u-law (except 00h)); "1100" = CN Packet (one/multi byte, white/pink, external); others = reserved. This field is a pointer to an RX RTP Channel Structure that will be used to complete packet processing, sending it either to the TDM bus in PCM or HDLC format, or to an RX CPU Packet queue. This address points to increments of 32 bytes.
RX RTP Channel Structure Address
Table 29 - Fields and Description (continued)
The format of the Payload Type/Marker Bit Table is the following:
b 15 b14 b13 b12 b11 b10 b9 +0 +2 Entry 0 Entry 4 Entry 1 Entry 5 b8 b7 b6 b5 b4 b3 b2 b1 b0
Entry 2 Entry 6
Entry 3 Entry 7
+7C +7E
Entry 248 Entry 252
Entry 249 Entry 253
Entry 250 Entry 254
Entry 251 Entry 255
Figure 47 - Payload Type/Marker Bit Table Field
Entry 0 Entry 1 Entry 254 Entry 255 Note
Description
M = `0' & PT = 0x00 (RTP), UDP Payload Len = 0 bytes (UDP) M = `0' & PT = 0x01 (RTP), UDP Payload Len = 1 bytes (UDP) M = `1' & PT = 0x7E (RTP), UDP Payload Len = 254 bytes (UDP) M = `1' & PT = 0x7F (RTP), UDP Payload Len = 255 or more bytes (UDP) Structure is 128 bytes long and must start on a 128-byte boundary. Each entry contains a 4-bit number used to select one of the 16 RX RTP Channel Structures to continue packet processing.
Table 30 - Fields and Description
Zarlink Semiconductor Inc.
91
MT92210
Data Sheet
RTP connections can generate Event Reports when special events or errors occur. These Event Reports indicate all UDP and RTP packaging errors encounters while parsing the packet. This includes fatal errors like UDP Checksum Error, RTP Version Mismatch and Bad packet Length 1 (which indicates that the RTP headers were too long for the packet length). It also reports structure Initialization, RTP packet Loss (detected through the sequence numbers) and Payload Type Report, which is set when the Report bit associated to the RX RTP Channel Structure is set. This structure reports the current packet's sequence number and the sequence number of the previous received packet (when RTP is enabled), as well as the Payload Type and Marker bit for RTP packets or the UDP Payload Length for UDP-only packets. The current Local Bus Timestamp is also written in the structure. These errors are documented in the following figure that gives the format of these events:
b15 b14 b13 b12 b11 b10 b9 +0 +2 +4 +6 +8 +A +C +E M I L R
b8 BL1
b7
b6
b5
b4
b3 0
b2 0
b1 0
b0 1
RVM UCE
RX RTP Connection Base Address [20:5] Payload Type [6:0] UDP Payload Length [7:0]
Previous RTP Sequence Number [15:0] This RTP Sequence Number [15:0] Local Bus Time Stamp [31:16] Local Bus Time Stamp [15:0]
Figure 48 - RX Disassembly Event Report Queue - RTP Connection Report Field
I L
Description
Set at reception of the first packet on the RX Connection Structure. Loss of one or many RTP packets detected because the sequence number fields of two consecutive packets were not incremental. The Previous and Current Sequence Numbers will indicate number of lost packets. This bit is set when the R bit is set in the RX Channel Structure Split Entry (as taken for the packet). Bad Packet Length 1. When set, a packet has been received with insufficient bytes to contain an RTP header. It will be discarded entirely. RTP Version Mismatch. When `1', this means that a packet was received with RTP version not equal to 2. UDP Checksum Error. When set, a packet has been received with an incorrect UDP checksum. Base address of the RX RTP Connection Structure that generated this report structure.
R BL1 RVM UCE RX RTP Connection Structure Address M & Payload Type
Theses two fields contain the value of the Marker bit and Payload Type of the RTP packet that caused this error structure to be generated.
Table 31 - Fields and Description
92
Zarlink Semiconductor Inc.
Data Sheet
Field
UDP Payload Length Previous RTP Sequence Number This RTP Sequence Number Local Bus Time Stamp
MT92210
Description
This field contains the length of the UDP payload of the received packet that caused this structure to be generated. If the UDP Payload is longer than 255 bytes, this field will be saturated at value 255. RTP Sequence number of the second last packet that was received. RTP Sequence number of the last packet that was received. Local Bus Time Stamp present at the time of reception of the packet that caused this report structure to be generated.
Table 31 - Fields and Description (continued)
8.2
xxPCM Treatment
In xxPCM, packet loss and adjustment can be performed by using the timestamps of the received packets. If the LE (Loss Enable) bit is set, the module will perform packet loss/misinsertion compensation by adjusting its pointer by the number of TDM frames that have elapsed. This is very useful when performing silence suppression, where the loss of packets is not only accepted but expected. In practice, Loss Enable should always be set except in UDP, where there is no timestamp to measure time with. The Last Packet Remote Timestamp, as well as the current timestamp of the packet, are used for this purpose in RTP. The remaining fields in the xxPCM RX Channel structure are mostly used for error reporting and monitoring. AR (Always Report) and SR (Slip Report) each indicate whether or not an error of the given type will cause an error structure to be generated. Note that if an error structure is generated, all errors that occurred on that packet will be reported, regardless of their Enable bit. The extension structure contains a 16-bit Received Packet count and a 32-bit Received Octet Count. These have the same definition as those in the disassembly structure (i.e. count UDP payload), but since all packets that are treated by this structure are valid UDP/RTP packets, they will all be included in the counts. It is important that the size of the payload in each packet be a multiple of the number of bearers present on the connection: if not, the BL2 bit (Bad Packet Length 2) in the RX error report structure will be flagged. Finally, at the very end of the structure, are a certain number of Circular Buffer Base Addresses that indicate, for each channel in the connection, where is the circular buffer associated to it. These addresses point to 256 byte boundaries, which is the smallest allowed size for any RX circular buffer. The buffers can be between 256 bytes and 4K bytes in size, as indicated by the Buffer Size field. xxPCM channels can receive CN packets in addition to normal packets filled with voice payload. Two types of CN packets can be received: single-byte, "white" packets that indicate only an energy level, and multi-byte, "spectral" packets containing both an energy level and spectral information. RX xxPCM channel structures can generate clock recovery pulses to the clock recovery module to indicate the arrival of packets. The MT92210 allows 2 redundant clock recovery circuits to run simultaneously, so the extension structures contain 2 bits, clock recovery A and clock recovery B, which the structure used to generate pulses. When it generates packet arrival pulses to the clock recovery module, the disassembly process also sends it the timestamp and the sequence number of the current packet (if RTP is being used). This will more accurately allow the clock recovery process to reconstruct the relationship between mclk and the packet arrival rate.
Zarlink Semiconductor Inc.
93
MT92210
The format of the xxPCM RX RTP Channel Structure is the following:
b 15 b14 b13 b12 b11 b10 b9 +0 +2 +4 +6 +8 +A +C +E +10 +12 +14 +16 +18 +1A +1C +1E +20 +22 +24 +26 +28 +2A RPM Number of Samples in Last Packet [10:0] Max Expected Payload Size in Samples [10:0] Maximum Used Samples in Circular Buffer[13:0] Init Lead [13:0] Underrun Lead [13:0] Overrun Lead [13:0] Minimum Delta [31:16] Minimum Delta [15:0] Maximum Delta [31:16] Maximum Delta [15:0] Last Packet Remote Time Stamp [31:16] Last Packet Remote Time Stamp [15:0] Received Packet Count [15:0] Received Octet Count [31:16] Received Octet Count [15:0] Channel 0 - Circular Buffer Base Address [20:8] Channel 1 - Circular Buffer Base Address [20:8] Channel 2 - Circular Buffer Base Address [20:8] A B b8 b7 b6 b5 b4 b3 b2 b1 b0
Data Sheet
RTP Common PDV Absorption Structure Pointer [20:5] AR SR LE PLX FL CPE Buf Size
Max CN Packet Length
Number of Channels [7:0] I
+220 +222
Channel 253 - Circular Buffer Base Address [20:8] Channel 254 - Circular Buffer Base Address [20:8]
Figure 49 - RX RTP xxPCM Channel Structure
94
Zarlink Semiconductor Inc.
Data Sheet
Field
RTP Common PDV Absorption Structure Pointer A Description
MT92210
Pointer to PDV monitoring and absorption structure that will be used by this channel. This pointer is in units of 32 bytes. Clock Recovery channel A. When this field is set, an Adaptive Clock Recovery RTP Event Structure using this packet's sequence number and time stamp fields will be written to the Adaptive clock recovery queue A. Clock Recovery channel B. When this field is set, an Adaptive Clock Recovery RTP Event Structure using this packet's sequence number and time stamp fields will be written to the Adaptive clock recovery queue B. Always Report Enable. Always generate an RX Disassembly Event Report Structure when a packet is received and this field is set. Used for debugging only. Slip Report Enable. When this field is set, any underrun or overrun will be reported via an RX Disassembly Event Report Structure. Packet Loss Compensation Enable. When set, the RTP time stamp will be used to align packets in the RX circular buffer for proper dejittering. When cleared, packets will be written back-to-back in the RX Circular buffer regardless of their time stamp. Report packets that are longer than expected. When this field is set and a packet is received containing more than Max Expected Payload Size in Frames payload samples, an RX Disassembly Event Report Structure will be generated. Report packet loss. When this field is set and Packet Loss Compensation is set, packets received that are not written immediately after the last received packet in the RX circular buffer will cause an RX Disassembly Event Report Structure to be generated (indicating a packet loss). CN PDV Monitoring Enable. When cleared, CN packets will not affect PDV monitoring fields. When set, CN packet will be assumed to contain as many frames as the last packet that was received. This assumption may not always be correct when the number of samples in a packet changes in time. RX Circular Buffer Size. This field indicates the size of RX Circular Buffer that will be used to dejitter incoming packets. "000" = 256 bytes; "001" = 512 bytes; "010" = 1024 bytes; "011" = 2048 bytes; "100" = 4096 bytes; others = reserved. CN packets longer than this value will be truncated to this length. This field contains the number of channels that are interleaved in a T1/AAL1 like manner in each packet. The field ranges between 1 and 255. Reset PDV Monitoring. When this bit is written to `1' by the software, the next received packet will begin a new PDV monitoring period and, at the time of the reception of that packet, the RPM bit will be cleared automatically by the hardware. When PDV monitoring is reset, the Minimum Delta and Maximum Delta are set to the delta of the first packet received in the new PDV monitoring period.
B
AR SR LE
PLX
FL
CPE
BS
Max CN Packet Length Number of Channels RPM
Table 32 - Fields and Description
Zarlink Semiconductor Inc.
95
MT92210
Field
I Number of Samples in Last Packet Max Expected Payload Size in Samples Maximum Used Samples in Circular Buffer Init Lead Description
Data Sheet
Initialized bit. This bit is written to `0' by software at channel initialization. It will be written to `1' by the hardware upon the reception of the first packet. This field contains the number of samples received in the last packet. It should be initialized to zeros upon channel initialization. This field indicates the maximum number of samples that are expected per packet received on this channel. Setting this field correctly ensures that changes in the number of samples per packet do not cause any slips. If the number of samples in a packet is unknown, this field should be set to 0. This is the number of samples used for packetization delay absorption and PDV absorption. A value of 0 will accept 1 samples packets with no PDV. For the typical case of 160 byte packets with 32 ms of PDV, a value of 160 + 256 - 1 = 415 will be written here. Position at which the first received sample will be written in the RX circular buffer. A value of 0 in this field means that the first received sample of the first packet will be sent on the H.110 bus immediately after reception. This field is in units of 1 frame. This field is usually set to the Expected PDV / 2. Position at which the first received sample in an underrun packet will be written in the RX circular buffer. This field is typically 8 frames. Position at which the first received sample in an overrun packet will be written in the RX circular buffer. This field is typically Expected PDV / 2. PDV Monitoring Field used to indicate the minimum delta that was monitored between the local timestamp and the remote time stamp. PDV Monitoring Field used to indicate the maximum delta that was monitored between the local time stamp and the remote time stamp. This field contains the last packet received remote time stamp. Total number of packets received on this channel so far. Every packet that gets to this structure will be included. Total number of bytes received on this channel so far (RTP header + payload included). Every packet that gets to this structure will be included. Base address of the circular buffer where a given channel is written. This base address is in units of 256 bytes. When only one channel is present (i.e. Number of Channels = 1), only the first Circular Buffer Base Address needs to be programmed of the 255 possible base addresses.
Underrun Lead Overrun Lead Minimum Delta Maximum Delta Last Packet Remote Time Stamp Received Packet Count Received Octet Count Circular Buffer Base Address
Table 32 - Fields and Description (continued)
Treatment of xxPCM channels can produce Event Reports that contain xxPCM-specific errors: Underrun errors, Underrun 2 errors, Overrun errors, as well as BL2 (Bad Packet Length 2) which means that the number of payload samples was not divisible by the number of bearers, and the BL3 (Bad Packet Length 3) which means that the packet was too large to fit in the circular buffer. If any samples were lost, the SL bit will be set, and the number of lost samples will be reported in the 32-bit Samples Lost field. Initialization of the channel in the RX xxPCM Channel Structure, or the I2, Initialization in the Common PDV Absorption Structure can also be reported. In addition to reporting all these errors, the xxPCM report structure gives the base address of the RX xxPCM Channel structure (to identify the channel to which the report structure belongs), the current Local Bus Timestamp and the current Remote Timestamp.
96
Zarlink Semiconductor Inc.
Data Sheet
The format of the xxPCM Event Report is the following:
b15 b14 b13 b12 b11 b10 b9 +0 +2 +4 +6 +8 +A +C +E U2 U O I I2 RPM RSx b8 b7 b6 b5 b4 b3 b2 b1 b0 0
MT92210
SL BL2 PLX BL4 BL3 XD
RX xxPCM Channel Structure Address [20:5] Samples Lost [31:16] Samples Lost [15:0] Remote Time Stamp [31:16] Remote Time Stamp [15:0] Local Bus Time Stamp [31:16] Local Bus Time Stamp [15:0]
Figure 50 - RX Disassembly Event Report Queue - xxPCM Channel Report Field
U2
Description
Underrun Detected 2. This bit is set when a packet is received with a remote time stamp that would require the first sample of the packet to be output on the TDM bus one or many frames ago. This means that the received packet was late as compared to its expected arrival time. Underrun Detected. This bit is set when a packet is received with a remote time stamp that would require the first sample of the packet to be output on the TDM bus one or many frames ago after the worst expected packetization delay was added to the arrival time. For example, if a 44 sample PCM packet is processed by a structure that expects 88 samples as the maximum packet size, it may only be output on the TDM bus in 44 frames; a received time stamp that would contradict this requirement would cause an underrun slip. Overrun Detected. This bit is set when a packet is received with a remote timestamp and number of samples that require the last sample of the packet to be sent out on the TDM bus with a delay greater that the Maximum Used Samples in Circular Buffer. When set, a packet has been received for the first time by the RX xxPCM Channel Structure. When set, a packet has been received for the first time by the Common PDV Absorption structure. Reset PDV Monitoring Completed. When this bit is set, the RPM bit in the RX xxPCM Channel Structure has been cleared by hardware and a new PDV monitoring period has been started. Reset Total Slip Offset Delta Completed. When this bit is set, the Total Slip Offset Delta has been reset in the Common PDV Absorption structure. Samples lost. When set, the Samples Lost[31:0] field is non-zero, meaning that one or many samples have been lost between packets.
U
O
I I2 RPM
RSx SL
Table 33 - Fields and Description
Zarlink Semiconductor Inc.
97
MT92210
Field
BL2
Data Sheet
Description
Bad Packet Length 2. When set, the number of "payload bytes" * 8 was not divisible "Number of channels" * "Number of bits per sample". Packets affected by this error will be discarded. Packet Longer than Expected. The number of samples in the received packet exceeded the "Max Expected Payload Size in Samples" field of the RX xxPCM Channel Structure, Bad Packet Length 4. The number of samples in the received packet exceeded 2047 frames. Bad Packet Length 3. The number of samples in the received packet was 0 frames. Extreme Delay. When `1', extreme delay has been detected in the Extended PDV monitoring structure. Base address of the RX xxPCM Channel Structure that generated this report structure. Number of samples lost due to packet loss as detected by the difference between remote time stamps in two consecutive packets. Remote time stamp of the packet received that cause the generation of this report structure. Local Bus Time Stamp present at the time of reception of the packet that caused this report structure to be generated.
PLX
BL4 BL3 XD RX xxPCM Channel Structure Address Samples Lost Remote Time Stamp Local Bus Time Stamp
Table 33 - Fields and Description (continued)
8.3
Packet Delay Variation (PDV) Monitoring
The MT92210's PDV monitoring writes packets within a PDV window, minimizing delay while trying to avoid slips. To do this, it writes packets based on their remote timestamp: a packet's position in the circular buffer is decided by its RTP timestamp. This allows compensation for packet loss and misinsertion. Because some profiles in RTP use varying-length packets (the term varying-length here refers to changing number of samples per packet, not length in bytes; compressed packets are converted to a number of samples before PDV monitoring is applied to them), changing packets lengths will show up as PDV on the network. To compensate for this, the xxPCM channel structure contains a Max Expected Payload Size in Samples field. Any variation in packet length up to this size will be compensated for. Setting this field to too large a value will insert delay; setting this field to too small a value will allow the changing length to show up as PDV. If the value is not known with certainty, a smaller value is usually better. The default mode of the PDV monitoring system allows a PDV window of length Maximum Used Samples in Circular Buffer. (Note: the Max Expected Payload Size in Samples - 1 must be added to Maximum Used Samples in Circular Buffer to get a window of the desired size. As an example, if the Max Expected Payload Size in Samples is 160 and the desired PDV window is 10 ms (80 samples) long, then Maximum Used Samples in Circular Buffer should be set to 239 (80 + (160-1)). An underrun occurs when not enough data is received by the disassembly module, so the desired write pointer's lead vs. the TDM read pointer would be smaller than 0. In this case, the write pointer's position is reset to Underrun Lead + current TDM read pointer. An overrun occurs when too much data is received by the disassembly module, so the desired write pointer's lead vs. the TDM read pointer would be greater than Maximum Used Samples in Circular Buffer. In this case, the write pointer's position is reset to Overrun Lead + current TDM read pointer. Finally, the Init Lead is used to reset the write pointer when the first packet is received on the channel.
98
Zarlink Semiconductor Inc.
Data Sheet
MT92210
The Underrun Lead and Overrun Lead are used to control the size of slips when they occur. Some algorithms prefer to place both the Underrun Lead and Overrun Lead at the center of the buffer, which minimizes the number of slips, but causes large slips and may add as much as (Maximum Used Samples in Circular Buffer / 2) of extra delay. Another possible algorithm is to place both the Underrun Lead and Init Lead to a small value K (e.g. 8 samples) and the Overrun Lead to (Maximum Used Samples in Circular Buffer - K). This causes slips of 8 bytes, may results in multiple slips, but ensures that no more than K samples of delay are ever inserted on the data. The MT92210 PDV monitoring may be used to control the end-to-end delay experienced on a given channel. To do so, the software initializes the Desired Remote/Local Timestamp Delta field to 0. This gives the expected delta between the timestamp in the RTP packet and the timestamp on the H.110 bus. The chip then Overruns and Underruns according to the need and settles within its PDV window. Each slip affects the Total Slip Offset Delta, which measures by how many samples the actual delta is off from the Desired Remote/Local Timestamp Delta. Software can then come and fix the Desired Remote/Local Timestamp Delta by adding to it the Total Slip Offset Delta and resetting the Total Slip Offset Delta. Note that a Total Slip Offset Delta of 12 and a Desired Remote/Local Timestamp Delta of 35 is the same as a Total Slip Offset Delta of 0 and a Desired Remote/Local Timestamp Delta of 47. The Minimum Delta gives the smallest value of Remote vs. Local delta seen so far (Minimum Delta means earliest packet, so the packet most likely to cause an overrun) while the Maximum Delta gives the largest value of Remote vs. Local delta seen so far (Maximum Delta means latest packet, so the packet most likely to cause an underrun). Thanks to this diagnostic, software can choose to change the Desired Remote/Local Timestamp Delta by another value, if, for example, the Maximum Delta indicates that a packet has been seen that would cause the current delta values to slip (this might be an indication that the PDV window is too small). If so, this will cause a slip and the software can choose when it wants the slip to occur. It can occur immediately, by setting the RSO (Reset Total Slip Offset Delta Once) bit, which will cause it to slip on the next packet. It can also wait for a packet with a marker bit = '1' by setting the RSM (Reset Total Slip Offset Delta on Marker). Finally, it can choose to reset when a significant amount of data has been lost by setting the RSL (Reset Total Slip Offset on Loss) bit. The Min Slip field defines what a "significant" amount of data is in 2n increments, between 2 ms and 256 ms. Some application may want the end-to-end delay to be fixed and unchanging, even in the case of slips. If that is the case, setting the RSA (Reset Total Slip Offset Delta Always) will ensure that the Total Slip Offset Delta never changes, which disables slips. This could lead to a loss of data integrity in the case of Underruns (or Overruns, but only if they manage to overflow the entire physical circular buffer, not only the section reserved by Maximum Used Samples in Circular Buffer). This end-to-end delay control may be used in several applications: * *
*
*
End-to-end slipless framing. This setup allows one or multiple PCM bearers to be transported end-to-end over a packet network without slips. Clear-channel DS3. Because the PDV monitoring allows multiple PCM channels to connect to a single Common PDV Absorption Structure, up to 1023 individual PCM bearers could use the same PDV information; this environment could tolerate slips where a single channel could cause a slip on all channels, maintaining the end-to-end delay across all channels. Interchip synchronization. Because the desired Remote/Local Timestamp delta is an absolute value (not relative to anything inside the chip), multiple chips can maintain the same end-to-end delay. The only requirement here is that all sources be capable of generating synchronized timestamps. MT92210 is capable of this because multiple chips can slave off the same H.110 bus timestamp. Glitchless fallback. Because multiple chips can maintain delay consistency, channels and connections can be swapped from one chip to another without a single byte loss.
The format of the RX RTP Common PDV Absorption structure is the following:
Zarlink Semiconductor Inc.
99
MT92210
b 15 b14 b13 b12 b11 b10 b9 +0 +2 +4 b8 b7 b6 b5 b4 b3 b2 b1
Data Sheet
b0 RSA
PSI XPE PSD Bus Time Stamp at which Last Packet was Received [31:16] Bus Timestamp at which Last Packet was Received [15:0] Min Slip IIL I2
+6 RSO RSL RSM +8 +A +C +E +10 +12 +14 +16 +18
Last Packet Remote Time Stamp [31:16] Last Packet Remote Time Stamp [15:0] Total Slip Offset Delta [31:16] Total Slip Offset Delta [15:0]
Desired Remote/Local Timestamp Delta [31:16] Desired Remote/Local Timestamp Delta [15:0] Reserved
Figure 51 - RTP Common PDV Absorption Structure Field
PSI
Description
Prevent Total Slip Offset Delta from incrementing. When `1', overrun slips will not cause the Total Slip Offset Delta from being changed. Overruns in this mode can only generate an RX Disassembly Event Structure. For proper data integrity behaviour, the software should correct the Total Slip Offset Delta manually when overruns occur and this bit is set. Write 0 for normal operation. Prevent Total Slip Offset Delta from decrement. When `1', underrun slips will not cause the Total Slip Offset Delta from being changed. In this mode, underruns can only generate an RX Disassembly Event Structure. For proper data integrity behaviour, the software should correct the Total Slip Offset Delta manually when underruns occur and this bit is set. Reset Total Slip Offset Delta Always. When this bit is set, all packets received will be written to the TDM bus at a time stamp delta exactly equal to the Desired Remote/Local Time Stamp Delta. Setting this bit gives controlling software full control of the de-jittering functionality. This field contains the local 32-bit bus time stamp that was present when the last received packet was processed by the PDV monitoring block.
XPE PSD
RSA
Bus Time Stamp at which last Packet was received
Table 34 - Fields and Description
100
Zarlink Semiconductor Inc.
Data Sheet
Field
RSO
MT92210
Description
Reset Total Slip Offset Delta when the next packet is received. When this bit is set by software, the next packet to be processed by the PDV monitoring block will cause the Total Slip Offset Delta to be reset to zero. The hardware will clear this bit immediately after the Desired Remote/Local Time Stamp delta has been applied. Reset Total Slip Offset Delta when the next packet is received after a significant silence period. When this bit is set by software, the next packet processed by the PDV monitoring block after a long period on inactivity (as defined by the Min Slip field) will cause the Total Slip Offset Delta to be reset to zero. The hardware will clear this bit immediately after the Desired Remote/Local Time Stamp Delta has been applied. Reset Total Slip Offset Delta when the next packet is received with the RTP marker bit set. When this bit is set by software, the next packet to be processed by the PDV monitoring block and whose RTP marker bit is set will cause the Total Slip Offset Delta to be reset to zero. The hardware will clear this bit immediately after the Desired Remote/Local Time Stamp delta has been applied. This field defines how many frames of lost data are considered enough to identify the gap as a silence period in order to cause the Total Slip Offset Delta to be reset when the RSL bit is set. "000" = 16 frames; "001" = 32 frames; "010" = 64 frames; "011" = 128 frames; "100" = 256 frames; "101" = 512 frames; "110" = 1024 frames; "111" = 2048 frames. Init with Init Lead. When this bit is set and a packet is received with the I2 bit cleared, the Total Slip Offset Delta will be set to the shortest allowed delay between the remote and local time stamp plus the Init Lead programmed in the RX RTP Disassembly Extension Structure. When this bit is cleared, the Desired Remote/Local Time Stamp Delta will be assumed to be correct and the normal underrun/overrun slipping will take place. Init bit. This bit must be written to zero by software when the structure is initialized. When the first packet is processed by this structure, the I2 bit will be written back to `1' by the hardware. 32-bit time stamp at which the packet was sent by the remote end (i.e. the RTP time stamp). When the RTP protocol is not present, this field simply increments by the number of frames received in the last packet. This "emulates" an RTP time stamp when no packet loss, misinsertion or silence suppression has occurred since the last packet arrival. This value is the current number of frames either added or dropped due to overruns and underruns. A positive number represents overruns and a negative number represents underruns. Note that underrun frames and overruns frames cancel-out in this field.
RSL
RSM
Min Slip
IIL
I2
Last Packet Remote Time Stamp
Total Slip Offset Delta
Table 34 - Fields and Description (continued)
Zarlink Semiconductor Inc.
101
MT92210
Field
Desired Remote-Local Time Stamp Delta
Data Sheet
Description
This field contains the desired local/remote time stamp delta that should be applied to all received packets. A time stamp delta of zero means that a packet received with time stamp of zero would see its first byte output on the bus when the local bus time stamp is zero. This field should be written to zero at initialization time. Write 0 for normal operation. all remote/local time stamp deltas are calculated with the following equation: delta = remote_packet_timestamp - local_bus_timestamp;
Reserved Note
Table 34 - Fields and Description (continued)
102
Zarlink Semiconductor Inc.
Data Sheet
8.4 HDLC Treatment
MT92210
In the other case, the RX Channel Structure Address used points to an RX HDLC Channel structure. The RX HDLC Channel structure can do policing, report diagnostic, and indicate what type of framing to perform. The HDLC stream number indicates to which of the 512 HDLC streams the HDLC packets obtained here belong: this will allow a packet descriptor to be written in the queue of the correct stream. The Header Type bits indicate what should be the form of the HDLC header inserted on the RTP packets: zero, one or two bytes of address, and zero or one control bytes. The CRC bit indicates if a 16-bit CRC should be appended at the end of the RTP packet. If these fields are added, their values are contained in the HDLC Address and HDLC Control Byte fields in the control structure. Finally, the 16-bit Received Packet count and a 32-bit Received Octet Count are also present, to allow solid diagnostics. Before writing the HDLC RTP packet in its circular buffer, the disassembly performs all of the header, CRC and zero-insertion functions. The MT92210 supports 2 types of HDLC framing: bit-wise and byte-wise framing (see Annex for more details). The appropriate form of framing is applied to the entire packet (including headers and CRC) before the packet is written in its circular buffer. When the packet is ready, the disassembly consults an HDLC control structure that contains the base address of the circular buffer, as well as the current read and write pointers. If there is enough room left in the circular buffer, the disassembly will write the entire packet into the buffer, then write a packet descriptor indicating where the packet can be read and what its length is. It will also write back the new write pointer. The RX TDM can then read the packet descriptor and send the packet onto the TDM bus. RX HDLC channel structures also implement a policing mechanism that prevents misbehaving channels from flooding an entire HDLC stream. This policing is implemented using a leaky bucket approach: a Maximum Bucket Fill indicates how full the bucket may be before packets start to be discarded, and the Discharge Rate indicates how quickly the bucket should be emptied. The bucket's fill is always positive, so in the best-case scenario the fill is 0. This ensures that, even if a connection has not received a packet for an infinite amount of time, it will not accept an infinite size packet when it does receive one! Whenever a packet is received, the bucket is first "discharged": this means that the amount of time elapsed since the last received packet is calculated and is subtracted from the Current Bucket Fill. Then, the new packet's size is added to the bucket. If the result is larger than the Maximum Bucket Fill, the packet will be discarded, an Event Report structure will be generated containing the Policing Error bit set, and the current packet's fill will not be added to the Current Bucket Fill. A well-configured policing mechanism can ensure that the circular buffer never overflows. The format of the RX RTP HDLC channel structure is the following:
b 15 b14 b13 b12 b11 b10 b9 +0 +2 +4 +6 +8 +A +C +E +10 +12 +14 A B HT 0 AR 0
b8
b7
b6
b5
b4
b3
b2
b1 b0
RX HDLC Stream/Buffer Index [8:0]
HDLC Address [15:0] 0 HDLC Control [7:0] Header Type CRC
Discharge Rate [5:0] Maximum Bucket Fill [15:0] Last Packet Local Time Stamp [23:8] Last Packet Local Time Stamp [7:0] I
Current Bucket Fill [21:16]
Current Bucket Fill [15:0] Received Packet Count [15:0] Received Octet Count [31:16] Received Octet Count [15:0]
Figure 52 - RX RTP HDLC Channel Structure
Zarlink Semiconductor Inc. 103
MT92210
Field
A
Data Sheet
Description
Clock Recovery channel A. When this field is set, an Adaptive Clock Recovery RTP Event Structure using this packet's sequence number and time stamp fields will be written to the Adaptive clock recovery queue A. Clock Recovery channel B. When this field is set, an Adaptive Clock Recovery RTP Event Structure using this packet's sequence number and time stamp fields will be written to the Adaptive clock recovery queue B. HDLC Encapsulation type. `0' = HDLC Bit-wise; `1' = HDLC Byte-wise. Always Report Enable. Always generate an RX Disassembly Event Report Structure when a packet is received and this field is set. Used for debugging only. Index in the RX HDLC Stream/Buffer Control Table in SSRAM B. Field that may be inserted in the HDLC packet header, depending on the Header Type. Field that may be inserted in the HDLC packet, depending on the Header Type. Long term rate at which bytes can be received on this HDLC channel. The current bucket fill is reduced at this rate. The rate is defined as a number of bytes per frame that can be sent on the HDLC stream (including all forms of HDLC framing). This is a floating point number; it has two bits of mantissa (excluding the hidden leading `1') and 4 bits of exponent. Zero is not a legal value. The minimum rate is 4 kbps, which is defined as mantissa = "100" and exponent = "0001". So to calculate the rate, the following equation can be used: 4 kbps * (mantissa/8) * (2^exponent). This can be set to: "000"=Plain; "001"=One byte address; "010"=Two byte address; "011"=One byte address + Control; "100"=Two byte address + Control; others = reserved. `0' = no CRC bytes will be appended to the HDLC packet; `1' = a 16-bit CRC-16 (otherwise known as CRC-CCITT) will be inserted at the end of the HDLC packet. Up to this many bytes can be contained in the "policing bucket" of this HDLC channel before packet discarding takes place. Largest value is 0x0000 (which means 65536 bytes), smallest value is 0x1 (which means 1 byte). Current Bucket Fill. Current fill of the "policing bucket" in 1/64th of a byte. This field should be initialized to all zeros by software. Time stamp in frames of the last received packet used to determine the time delta between the reception of HDLC packets. Used to discharge the Current Bucket Fill. Initialized bit. Written to zero by software channel initialization. Written to `1' by hardware as soon at the first packet is received on this channel. Total number of packets received on this channel so far. Every packet that gets to this structure will be included.
B
HT AR RX HDLC Stream/Buffer Index HDLC Address HDLC Control Discharge Rate
Header Type
CRC Maximum Bucket Fill
CBF Last Packet Local Time Stamp I Received Packet Count
Table 35 - Fields and Description
104
Zarlink Semiconductor Inc.
Data Sheet
Field
Received Octet Count
MT92210
Description
Total number of bytes received on this channel so far. Every packet that gets to this structure will be included. This field increments by the UDP Length - 8 each time packet is received.
Table 35 - Fields and Description (continued)
As in xxPCM, the RX HDLC channel structure can request the generation of clock recovery events. It can also generate Event Reports, the format of which is the following:
b15 b14 b13 b12 b11 b10 b9 +0 +2 +4 +6 +8 +A +C +E Packet Base Pointer [15:0] Packet Length [11:0] Local Bus Time Stamp [31:16] Local Bus Time Stamp [15:0] I b8 b7 PE b6 b5 b4 PL b3 0 b2 0 b1 1 b0 1
RX Channel Structure Address [20:5] RX Connection Structure Address [20:5]
Figure 53 - RX Disassembly Event Report Queue - HDLC / CPU Channel Report Field
I PE PL RX Channel Structure Address RX Connection Structure Address Packet Base Pointer Packet Length Local Bus Time Stamp
Description
Set at the reception of the first packet on this RX HDLC/CPU Channel Structure. Policing Error. Indicates that the HDLC / CPU packet was discarded because it caused the policing bucket to overflow. Packet Lost. When set, this bit indicates that a packet was lost due to the lack of room in the Circular buffer to which this packet was to be written. Base address of the RX HDLC/CPU Channel Structure that generated this report structure. Base address of the RX Connection Structure that led to the RX Channel Structure which generated this report structure. Pointer to the first voice byte of this packet in the RX Circular buffer. The pointer is relative to the base address of the RX Circular Buffer. This field is only defined for RX CPU Packets. Length of the packet in bytes defined by the number of actual bytes used in the circular buffer. This field is only defined for RX CPU Packets. Local Bus Time Stamp present at the time of reception of the packet that caused this report structure to be generated.
Table 36 - Fields and Description
Zarlink Semiconductor Inc.
105
MT92210
8.5 CPU Treatment
Data Sheet
The CPU manages its packets in much the same way as an HDLC stream does: it reserves a circular buffer of a certain size and even reserves RX CPU Buffer Control Tables in much the same was HDLC streams use RX HDLC Stream/Buffer Control Tables. All channels may write their packets into that circular buffer. Each CPU packet received will generate an error report structure and they can be retrieved through the pointers these structures contain. The CPU may even choose to route its packets to several different circular buffers. Finally, the CPU can also receive an interrupt informing it that its circular buffers are getting "too full": if any of the CPU-destined circular buffers becomes more than half full, an interrupt can be generated. The CPU can then read the report structure FIFO and empty all circular buffers of their packets. The RX CPU Channel Structure also implements the same type of policing found in HDLC, for exactly the same reasons. A misbehaving channel should not be able to flood the CPU with packets, preventing other, well-behaved channels from getting attention. The fields in the RX CPU Channel Structure are identical to those in the RX HDLC Channel Structure. The format of the RX CPU Buffer Control Table is the following:
1000h 1008h
RX CPU Buffer Control Structure 0 RX CPU Buffer Control Structure 1
1FFCh 1FFEh
RX CPU Buffer Control Structure 510 RX CPU Buffer Control Structure 511 The RX CPU Buffer Control Table is at a fixed address in SSRAM B. It always contains 512 entries.
b 15 b14 b13 b12 b11 b10 b9 +0h +2h +4h +6h
b8
b7
b6
b5
b4
b3
b2
b1
b0
RX Circular Buffer Base [20:8] and Size Circular Buffer Write Pointer [15:0] Circular Buffer Read Pointer [15:0]
Figure 54 - Rx CPU Buffer Control Table
Add
Field
RX Circular Buffer Base and Size Circular Buffer Write Pointer
Description
This field indicates the location and the size of the buffer that it used to store packets before they are read by the software. Supported size are between 256 bytes and 64K bytes in step of 2^k. This pointer is used to remember the position of the next byte to be written in the circular buffer. It thus points to an invalid byte. The pointer is defined as a pointer to bytes. This field should be initialized to zero upon buffer creation.
Table 37 - Fields and Description
106
Zarlink Semiconductor Inc.
Data Sheet
Field
Circular Buffer Read Pointer
MT92210
Description
This pointer is used to remember the position of the next byte to be read in the circular buffer. It thus points to a valid byte. The pointer is defined as a pointer to bytes. When the read and write pointers are equal, the buffer is deemed empty. This field should be initialized to zero upon buffer creation. It is control by software and should be updated each time a packet is read from the circular buffer.
Table 37 - Fields and Description (continued)
b13 b12 b11 b10 b9 256 bytes:
b8
b7
b6
b5
b4
b3
b2
b1
b0 1
RX Circular Buffer Base [20:8] b13 b12 b11 b10 b9 b8 b7 b6 b5 b4 b3 b2 b1 1 b4 b3 b2 1 b4 b3 1 b5 b4 1 b5 1 b6 1 b6 0 b6 0 b5 0 b5 0 b5 0 b4 0 b4 0 b4 0 b4 0 b3 0 b3 0 b3 0 b3 0 b3 0 b2 0 b2 0 b2 0 b2 0 b2 0 b2 0 b1 0 b1 0 b1 0 b1 0 b1 0 b1 0 b1 0
b0 0 b0 0 b0 0 b0 0 b0 0 b0 0 b0 0 b0 0
512 bytes:
RX Circular Buffer Base [20:9] b13 b12 b11 b10 b9 b8 b7 b6 b5
1K bytes:
RX Circular Buffer Base [20:10] b13 b12 b11 b10 b9 b8 b7 b6 b5
2K bytes:
RX Circular Buffer Base [20:11] b13 b12 b11 b10 b9 b8 b7 b6
4K bytes:
RX Circular Buffer Base [20:12] b13 b12 b11 b10 b9 b8 b7 b6
8K bytes:
RX Circular Buffer Base [20:13] b13 b12 b11 b10 b9 b8 b7
16K bytes:
RX Circular Buffer Base [20:14] b13 b12 b11 b10 b9 b8 b7 1 b7 0
32K bytes:
RX Circular Buffer Base [20:15] b13 b12 b11 b10 b9 b8 1
64K bytes:
RX Circ Buf Base [20:16]
Figure 55 - RX Circular Buffer Base and Size
Zarlink Semiconductor Inc.
107
MT92210
The format of the RX RTP CPU Channel Structure is the following:
b 15 b14 b13 b12 b11 b10 b9 +0 +2 +4 +6 +8 +A +C +E +10 +12 +14 A B 1 1 1 1 0x0000 HFE Discharge Rate [5:0] Maximum Bucket Fill [15:0] Last Packet Local Time Stamp [23:8] Last Packet Local Time Stamp [7:0] I Current Bucket Fill [21:16] 0x00 0 0 0 0 b8 b7 b6 b5 b4 b3 b2 b1 b0
Data Sheet
RX CPU Buffer Index [8:0]
Current Bucket Fill [15:0] Received Packet Count [15:0] Received Octet Count [31:16] Received Octet Count [15:0]
Figure 56 - RX RTP CPU Channel Structure Field
A
Description
Clock Recovery channel A. When this field is set, an Adaptive Clock Recovery RTP Event Structure using this packet's sequence number and time stamp fields will be written to the Adaptive clock recovery queue A. Clock Recovery channel B. When this field is set, an Adaptive Clock Recovery RTP Event Structure using this packet's sequence number and time stamp fields will be written to the Adaptive clock recovery queue B. Index in the RX CPU Buffer Control Table in SSRAM B. Half Full Interrupt Enable. When `1', if the RX CPU Buffer for this channel is more than half full, the interrupt_error_alarm will be forced active. This alarm should force the software to empty out packets in all RX CPU buffers. Long term rate at which bytes can be received on this RX CPU channel. The current bucket fill is reduced at this rate. The rate is defined as a number of bytes per frame that can be sent into the RX CPU buffer. This is a floating point number; it has two bits of mantissa (excluding the hidden leading `1') and 4 bits of exponent. Zero is not a legal value. The minimum rate is 4 kbps, which is defined as mantissa = "100" and exponent = "0001". So to calculate the rate, the following equation can be used: 4 kbps * (mantissa/8) * (2^exponent). Up to this many bytes can be contained in the "policing bucket" of this RX CPU channel before packet discarding takes place. Largest value is 0x0000 (which means 65536 bytes), smallest value is 0x1 (which means 1 byte). Current Bucket Fill. Current fill of the "policing bucket" in 1/64th of a byte. This field should be initialized to all zeros by software.
B
RX CPU Buffer Index HFE
Discharge Rate
Maximum Bucket Fill
CBF
Table 38 - Fields and Description
108
Zarlink Semiconductor Inc.
Data Sheet
Field
Last Packet Local Time Stamp: I Received Packet Count: Received Octet Count
MT92210
Description
Time stamp in frames of the last received packet used to determine the time delta between the reception of RX CPU packets. Used to discharge the Current Bucket Fill. Initialized bit. Written to zero by software channel initialization. Written to `1' by hardware as soon at the first packet is received on this channel. Total number of packets received on this channel so far. Every packet that gets to this structure will be included. Total number of bytes received on this channel so far. Every packet that gets to this structure will be included. This field increments by the UDP Length - 8 each time packet is received.
Table 38 - Fields and Description (continued)
Zarlink Semiconductor Inc.
109
MT92210
Data Sheet
110
Zarlink Semiconductor Inc.
Data Sheet
9.0 TX/RX TDM Data Paths
MT92210
This chapter describes the data paths for all bytes transmitted and received with the H.110 interface.
9.1
TX TDM Data Path
The TX TDM section of the chip takes bytes from the H.110 interface and writes them into circular buffers in SSRAM A. To do so, the MT92210 uses the TX Channel Association Memory to decide which of the 1023 time slots on the H.110 bus it wants to treat. Each entry in the TX Channel Association Memory associates a time slot with either a PCM buffer or an HDLC stream; the chip can support up to 1023 PCM buffers or up to 512 HDLC streams, or any combination of the two (two PCM buffers cost the same as 1 HDLC stream). Any of the 1023 time slots supported can also be configured as Low Latency Loopback: this means that the time slot will simply be looped back onto another time slot on the H.110 bus. This is the format of the TX Channel Association Memory:
80000h 80008h
Entry 0 Entry 1
81FF0h 81FF8h
Entry 1022 Entry 1023
TX Channel Association Memory Entry b 15 b14 b13 b12 b11 b10 b9 +0 +2 +4 AS +6 Stream/Buffer Tag TSST [11:0] Link to Next Entry b8 b7 b6 b5 b4 b3 b2 b1 b0
Figure 57 - TX Channel Association Memory Field
Stream/Buffer Tag AS
Description
Encoded field that points either to the TX TDM Control memory (for xxPCM Buffer and HDLC stream) or to the Low-Latency Loopback Memory for Low-Latency Loopback channels. Associated Stream. When set, the least significant bit of the TSST number will be ignored and both even and odd streams pointed to by the TSST number will be read for valid data. For xxPCM circular buffers, the extra stream allows PCM / ADPCM codec changes to occur smoothly. For HDLC streams, the extra stream doubles the bandwidth that is available on the HDLC stream. Time / Stream Number. TSST[11:5] represents the timeslot on which the data belonging to an HDLC stream or to an xxPCM buffer will be received from. TSST[4:0] represents the stream on which the data belonging to an HDLC stream or to an xxPCM buffer will be received from. Pointer to the next TX Channel Association Memory Entry. Entries must be sorted according to TSST number. Entry 0 is never considered to contain a Buffet Tag; it's TSST is hardcoded in the chip as number -1, which means that the last TX Channel Association Memory Entry must point back to Entry 0 to be ready for the next frame.
TSST
Link to next entry
Table 39 - Fields and Description
Zarlink Semiconductor Inc.
111
MT92210
b10 b9 1 b10 b9 0 1 b8 0 b8 b8 b7 b6 b5 b4 b3 b2 b1 b0
Data Sheet
:
PCM Buffer Number [9:0] b7 b6 b5 b4 b3 b2 b1 b0
HDLC Stream Number [8:0] b7 1 b6 b5 b4 b3 b2 b1 b0
b10 b9 0 0
LLL Buffer Number [6:0]
Figure 58 - Buffer Tag Format
The TX Channel Association Memory entry points to an entry in the TX TDM Control Memory that will define either a PCM buffer or an HDLC stream. If the entry defines a PCM buffer, it will define the compression type of the data to be received. The MT92210 can support TDM data in PCM A-law, PCM u-law, ADPCM-40, ADPCM-32, ADPCM-24 and ADPCM-16 formats. It can also perform auto-detection of the compression rate received using encoded values. Lastly, the TX TDM can perform law-translation on the incoming PCM values. The data can enter as either u-law or A-law and can also exit as either u-law or A-law, with any translation between the two. If the TX TDM Control Memory entry defines an HDLC stream, then the entry will contain information used to perform HDLC de-framing. Many fields are used to keep byte-per-byte context. The entry also contains fields specifying the HDLC header format: the chip supports HDLC addresses of 0, 1 or 2 bytes, as well as 0 or 1 HDLC control bytes. Each HDLC packet may also be trailed by a 16-bit CRC, configurable per stream. The HDLC addresses are used to distinguish multiple channels on the same HDLC stream, with a maximum of 512 channels per stream (using the 9 low bits of a 2-byte address), or a maximum of 256 channels when using a single-byte address. The TX Channel Association Memory also has an AS (Associated Stream) bit that allows greater bandwidth on HDLC streams. When this bit is `1', the TX Channel Association Memory binds 2 time slots to the corresponding TX TDM Control Memory entry instead of 1. This increases the total capacity of the TX Data Path in HDLC mode to 2046 time slots. In this mode, the 2 time slots that are bound together are 2 adjacent H.110 streams (i.e. ct_d[0] and ct_d[1], during the same time slot). The even stream contains the data that is logically first. Each HDLC stream is associated to a circular buffer, of varying size depending on the maximum packet size expected on that stream and the bandwidth of the stream. The circular buffer sizes can vary between 512 bytes and 32K bytes, in increments of 2n. The format of the TX TDM Control Memory is the following:
112
Zarlink Semiconductor Inc.
Data Sheet
A0000h A0008h A0010h A0018h A0020h A0028h A0030h A0038h A0040h xxPCM Buffer 0 or HDLC Buffer 0 xxPCM Buffer 1 or HDLC Buffer 0 xxPCM Buffer 2 or HDLC Buffer 1 xxPCM Buffer 3 or HDLC Buffer 1 xxPCM Buffer 4 or HDLC Buffer 2 xxPCM Buffer 5 or HDLC Buffer 2 xxPCM Buffer 6 or HDLC Buffer 3 xxPCM Buffer 7 or HDLC Buffer 3 xxPCM Buffer 8 or HDLC Buffer 4
MT92210
A1FF0h A1FF8h
xxPCM Buffer 1022 or HDLC Buffer 511 xxPCM Buffer 1023 or HDLC Buffer 511
TX HDLC Stream Structure b 15 b14 b13 b12 b11 b10 b9 +0 +2 Add [8:7] +4 +6 +8 Circular Buffer Read Point [5:0] 1's Cnt Add [6:0] History & Valid Buf Size b8 b7 b6 b5 b4 b3 b2 b1 b0
TX Circular Buffer Base [20:8] / SOP [14:5] HBC Write Offset [10:0]
+A HT Header Type CRC +C +E
TX xxPCM Buffer Structure b 15 b14 b13 b12 b11 b10 b9 +0 +2 +4 +6 b8 b7 b6 b5 b4 b3 b2 b1 b0
TX Circular Buffer Base [20:9] / Size Indication N IL OL C
Figure 59 - TX TDM Control Memory
Zarlink Semiconductor Inc.
113
MT92210
Field
TX Circular Buffer Base / Size Indication N IL OL C
Data Sheet
Description
This field indicates the base address and size of the circular buffer in which values received from the TDM bus must be written. The size range is 256 bytes to 1K bytes. Nibble mode. `0' = ADPCM nibbles in high bits; `1' = ADPCM nibbles in low bits. In law. Determines the PCM law of samples received from the TDM bus. `0' = u-law; `1' = A-law. Out law. Determines the PCM law of samples written to the TX Circular Buffer. `0' = u-law; `1' = A-law. Compression type. "000" = PCM, "001" = ADPCM 40 kbps, "010" = ADPCM 32 kbps, "011" = ADPCM 24 kbps, "100" = ADPCM 16 kbps; "101" = ADPCM only autodetect (Associated Stream bit is cleared); "110" = ADPCM & PCM autodetect (Associated Stream bit is set); "111" = reserved. Base address of the TX Circular Buffer used for the HDLC stream. The lower order bits of this field represent the start of packet address of the packet that is currently being received on the HDLC stream. The SOP part of this field should be written to zero by software upon initialization of the HDLC stream. HDLC Address of the current packet. This field should be initialized to zero by software upon initialization of stream. Header byte count. This field should be initialized to zero by software upon initialization of stream. This field indicates where the next received byte will be written in the TX Circular Buffer. This offset is calculated using the SOP as its base. This field should be initialized to zero by software upon initialization of stream. This field is updated by the TX assembly block when packets are sent out. This field should be initialized to zero by software upon initialization of stream. Circular Buffer Size. "000" = 256 bytes; "001" = 512 bytes; "010" = 1K bytes; "011" = 2K bytes; "100" = 4K bytes; "101" = 8K bytes; "110" = 16K bytes; "111" = 32K bytes. HDLC Type. `0' = bit wise packet framing and escape code; `1' = byte wise packet framing and escape code.
TX Circular Buffer Base [20:8] / SOP[14:5]: Add HBC Write Offset
Circular Buffer Read Pointer Buf Size
HT
Table 40 - Fields and Description
114
Zarlink Semiconductor Inc.
Data Sheet
Field
Header type "000"=Plain; "001"=One byte address; "010"=Two byte address; "011"=One byte address + Control; "100"=Two byte address + Control; others = reserved.
MT92210
Description
CRC 1's Cnt History & Valid:
CRC Present. When `1', a CRC16 is expected at the end of each HDLC Packet that is received. Counter of the number of consecutive `1' that have been received recently on the HDLC stream. This field should be initialized to "111" by software upon initialization of stream. This field contains partially received bytes from the HDLC stream. The number of bits received but pending byte completion can be established by locating the first `1' starting from the most significant bit of the field. This field should be initialized to "00000001" by software upon initialization of stream.
Table 40 - Fields and Description (continued)
b12 b11 b10 b9 512 256 Byte Buffer b8 b7 b6 b5 b4 b3 b2 b1 b0 1 b3 b2 b1 1 b3 b2 1 b1 0 b0 0 b0 0
:
TX Circular Buffer Base [20:9] b12 b11 b10 b9 b8 b7 b6 b5 b4
1K 512 Byte Buffer
TX Circular Buffer Base [20:10] b12 b11 b10 b9 b8 b7 b6 b5 b4
1K Byte Buffer
TX Circular Buffer Base [20:11]
Figure 60 - TX Circular Buffer Base/Size Indication
Zarlink Semiconductor Inc.
115
MT92210
b 15 b14 b13 b12 b11 b10 b9 256 Byte Buffer b8 b7 b6 b5 b4 b3 b2 b1 b0
Data Sheet
TX Circular Buffer Base [20:8] b 15 b14 b13 b12 b11 b10 b9 b8 b7 b6 b5 b4 b3
SOP [7:5] b2 b1 b0
512 Byte Buffer
TX Circular Buffer Base [20:9] b 15 b14 b13 b12 b11 b10 b9 b8 b7 b6 b5 b4 b3
SOP [8:5] b2 b1 b0
1K Byte Buffer
TX Circular Buffer Base [20:10] b 15 b14 b13 b12 b11 b10 b9 b8 b7 b6 b5 b4
SOP [9:5] b3 b2 b1 b0
2K Byte Buffer
TX Circular Buffer Base [20:11] b 15 b14 b13 b12 b11 b10 b9 b8 b7 b6 b5 b4
SOP [10:5] b3 b2 b1 b0
4K Byte Buffer
TX Circular Buffer Base [20:12] b 15 b14 b13 b12 b11 b10 b9 b8 b7 b6 b5
SOP [11:5] b4 b3 b2 b1 b0
8K Byte Buffer
TX Circular Buffer Base [20:13] b 15 b14 b13 b12 b11 b10 b9 b8 b7 b6 b5
SOP [12:5] b4 b3 b2 b1 b0
16K Byte Buffer
TX Circular Buffer Base [20:14] b 15 b14 b13 b12 b11 b10 b9 b8 b7 b6
SOP [13:5] b5 b4 b3 b2 b1 b0
32K Byte Buffer
TX Circ Buffer Base [20:15]
SOP [14:5]
:
Figure 61 - TX Circular Buffer Base/SOP
When an HDLC packet completes, an event must be written to the Assembly Event Queue so the packet makes it to the network interface. Each HDLC Stream has an entry in the HDLC Stream to HDLC Address LUT Structure, which gives, for each HDLC Stream, the list of all HDLC addresses and their corresponding TX Connection Structures. For each Stream, the number of valid addresses is defined (anywhere from 16 to 512 in increments of 16) as well as a pointer to the corresponding HDLC Address LUT. The format of the HDLC Stream to HDLC Address LUT Structure is the following:
b 15 b14 b13 b12 b11 b10 b9 400000h 400002h 400004h 400006h b8 b7 b6 b5 b4 b3 b2 b1 b0
HDLC Address LUT Base [20:6] for HDLC Stream 0 Add Range HDLC Address LUT Base [20:6] for HDLC Stream 1 Add Range
4007F8h 4007FAh 4007FCh 4007FEh
HDLC Address LUT Base [20:6] for HDLC Stream 510 Add Range HDLC Address LUT Base [20:6] for HDLC Stream 511 Add Range
Figure 62 - HDLC Stream to HDLC Address LUT Structure
In RTP, the HDLC Address LUT Structure contains a pointer to a TX Connection Structure, as well as a TI (Timestamp Insert) bit. When this bit is `1', this chip will insert its own timestamp, adding the one contained in the HDLC packet to the final timestamp. When `0', the timestamp in the HDLC packet will be used as-is.
116
Zarlink Semiconductor Inc.
Data Sheet
Field
HDLC Address LUT Base for HDLC Stream Add Range
MT92210
Description
This field serves to locate in external SSRAM A a look-up table used to associated HDLC addresses with TX Connection Structures. It points to 64-byte increments. Defines the size of the HDLC Address LUT Structure. "00000" = address ranges between 0 and 511; "00001" = address ranges between 0 and 15; "00010" = address ranges between 0 and 31; "00011" = address ranges between 0 and 47;...;"11111" = address ranges between 0 and 495. Indexing in this structure is done implicitly using the HDLC stream number in the TX TDM Control Memory. This table is consulted every time an HDLC packet reception completed.
Note
Table 41 - Fields and Description
The format of the RTP HDLC Address LUT Structure is the following:
b15 b14 b13 b12 b11 b10 b9 b8 b7 b6 b5 b4 b3 b2 b1 b0 +0 +2 +4 +6 TX Connection Structure Base [20:5] for Address = 1 0 TI TX Connection Structure Base [20:5] for Address = 0 0 TI
+(N-2)*4+0 +(N-2)*4+2 +(N-1)*4+0 +(N-1)*4+2
TX Connection Structure Base [20:5] for Address = N-2 0 TX Connection Structure Base [20:5] for Address = N-1 0 TI TI
Figure 63 - HDLC Address LUT (RTP) Field
TX Connection Structure Base for Address TI
Description
Base address of the TX Connection Structure that will be used to send HDLC packets with the address shown. When this field is 0000h, the address is deemed invalid and the packet is discarded. Time Stamp Insert. When `0', the time stamp will be inserted in the packet as it is received in the HDLC packet. When `1', the time stamp in the HDLC packet will be treated as an offset from the current bus time stamp. Number of HDLC addresses supported as defined by Add Range in the HDLC Stream to HDLC Address LUT Structure.
N
Table 42 - Fields and Description
9.2
TX TDM Data Formats
Zarlink Semiconductor Inc.
117
MT92210
Data Sheet
When interfacing with external compression or silence suppression agents in xxPCM, the MT92210 uses special data formats that allow it to pass more than payload information over the H.110 bus. When receiving ADPCM data, the position of the highest `1' in the data sample indicates the type of compression used: in this way, all ADPCM compression types can be encoded within a single payload byte. In addition, the 00h code is used to indicate a suppression decision. All of this information is coded within an 8-bit sample. The ADCPM sample may also be contained in the high bits of the byte: in this case, the decoding is reversed, the position of the lowest `1' in the data sample indicates the compression type. However, when the received data is ADPCM and silence suppression is being performed, the MT92210 is incapable of extracting the energy level of the silence from the ADPCM samples. Therefore, the magnitude of the original PCM value must be transmitted somehow to the MT92210. This is done on an associated stream, so a single sample of an xxPCM channel now occupies 2 H.110 TSSTs. When the compression type can be PCM or ADPCM, then an extra indication is necessary to indicate this compression type. Because the magnitude of the original PCM value is 7 bits, there is a single free bit left on the associated stream: this bit will be used to indicate if the compression of the current data is PCM or ADPCM. The remaining encoding of the data is done in the same way. In summary, single time-slot mode allows: * * * PCM samples with internal VAD for silence suppression and energy level detection. ADPCM samples with compression auto-detection ADPCM samples with compression auto-detection and silence suppression but no energy level detection. The CN packet will have to be programmed through the CPU interface. PCM and ADPCM samples with compression auto-detection ADPCM samples with compression auto-detection and silence suppression with energy level detection. PCM and ADPCM samples with compression auto-detection and silence suppression with energy level detection.
Dual time-slot mode allows: * * *
The format of the TX xxPCM TSSTs in single and dual time-slot mode is the following:
118
Zarlink Semiconductor Inc.
Data Sheet
TSST Grouping on H.110 (Associated Stream bit set) b7 TSSTn TSSTn+1 PCM b6 b5 b4 b3 b2 b1 b0 TSSTn TX PCM Unsigned Mag TX xxPCM Sample TSST Grouping on H.110 (Associated Stream bit cleared) b7 b6 b5 b4 b3 b2 b1 b0
MT92210
TX xxPCM Sample
TX Code Point Format (ADPCM samples in low bits) PCM 1 PCM 0 PCM 0 PCM 0 PCM 0 PCM 0 b7 0 b7 0 b7 0 b7 0 b7 0 b6 0 b6 0 b6 0 b6 0 b6 0 b5 1 b5 0 b5 0 b5 0 b5 0 b4 1 b4 0 b4 0 b4 0 b3 1 b3 0 b3 0 b2 1 b2 0 b7 b6 b5 b4 b3 b2 b1 b0 PCM 1 b2 b1 b0 PCM 0 b0 PCM 0 b0 PCM 0 b0 PCM 0 PCM 0
TX Code Point Format (ADPCM samples in high bits) b7 b6 b5 b4 b3 b2 b1 b0
PCM b4 b3
PCM b7 b6 b5 b4 b3 b2 1 b3 1 b4 1 b5 1 b5 0 b4 0 b4 0 b3 0 b3 0 b3 0 b2 0 b2 0 b2 0 b2 0 b1 0 b1 0 b1 0 b1 0 b1 0 b0 0 b0 0 b0 0 b0 0 b0 0
ADPCM 40kbps b3 b2 b1
ADPCM 40kbps b7 b6 b5 b4
32kbps b2 b1 24kbps b1
32kbps b7 b6 b5
24kbps b7 b6
16kbps b1 0 b0 0
16kbps b7 0 b6 0
Suppress packet ending with this sample.
Figure 64 - Format of TX xxPCM TSSTs
9.3
RX TDM Data Path
The RX TDM module is responsible for copying data from the circular buffers contained in SSRAM B and passing them on to the H.110 interface. The RX TDM uses an RX Channel Association Memory to associate each of the 1023 time slots it supports to either a PCM buffer or an HDLC stream. The chip can support up to 1023 PCM buffers or up to 512 HDLC streams, or any combination of the two (two PCM buffers cost the same as 1 HDLC stream). Any of the 1023 time slots supported can also be configured as Low Latency Loopback: this means that the data sent onto the time slot will not come from a circular buffer but will be received from another time slot on the bus, treated by the TX TDM. This is the format of the RX Channel Association Memory:
Zarlink Semiconductor Inc.
119
MT92210
Data Sheet
90000h 90008h
Entry 0 Entry 1
91FF0h 91FF8h
Entry 1022 Entry 1023
RX Channel Association Memory Entry b 15 b14 b13 b12 b11 b10 b9 b8 b7 +0 +2 +4 AS +6
b6
b5
b4
b3
b2
b1
b0
Stream/Buffer Tag TSST [11:0] Link to next entry
Figure 65 - RX Channel Association Memory
:
Field
Stream/Buffer Tag
Description
Encoded field that points either to the RX TDM Control memory (for xxPCM Buffer and HDLC stream) or to the Low-Latency Loopback Memory for Low-Latency Loopback channels. Associated Stream. When set, the least significant bit of the TSST number will be ignored and both even and odd streams pointed to by the TSST number will be driven out with valid data. For xxPCM circular buffers, the extra stream allows PCM / ADPCM codec changes to occur smoothly. For HDLC streams, the extra stream doubles the bandwidth that is available on the HDLC stream. Time / Stream Number. TSST[11:5] represents the timeslot on which the data belonging to an HDLC stream or to an xxPCM buffer will be sent on. TSST[4:0] represents the stream on which the data belonging to an HDLC stream or to an xxPCM buffer will be sent on. Pointer to the next RX Channel Association Memory Entry. Entries must be sorted according to TSST number (incrementally). Entry 0 is never considered to contain a Buffet Tag; it's TSST is hardcoded in the chip as number -1, which means that the last RX Channel Association Memory Entry must point back to Entry 0 to be ready for the next frame.
AS
TSST
Link to next entry
Table 43 - Fields and Description
b10 b9 1 b10 b9 0 1 b8 0 b8 b8 b7 b6 b5 b4 b3 b2 b1 b0
PCM Buffer Number [9:0] b7 b6 b5 b4 b3 b2 b1 b0
HDLC Stream Number [8:0] b7 1 b6 b5 b4 b3 b2 b1 b0
b10 b9 0 0
LLL Buffer Number [6:0]
Figure 66 - Stream/Buffer Tag Format
120
Zarlink Semiconductor Inc.
Data Sheet
Field
PCM Buffer Number HDLC Stream Number LLL Buffer Number
MT92210
Description
Points to 8-byte PCM entry in RX TDM Control Structure Points to 16-byte HDLC entry in RX TDM Control Structure (must be aligned on a 16-byte boundary) Points to LLL 4-byte circular buffer
Table 44 - Fields and Description
When the RX Channel Association Memory points to an RX xxPCM Buffer Structure in the RX TDM Control Memory, the entry contains a pointer to the RX circular buffer used. In addition, law translation can be done in the RX direction: the data coming from the circular buffer can be u-law or A-law and it can exit on H.110 as u-law or A-law. The RX xxPCM Buffer Structure contains a Padding Type field that indicates where padding data should come from if no valid data is available in the circular buffer, in the case of underruns or packet loss. The Padding Type field can be updated by the packet disassembly module: when a CN packet is received, a new Padding Type value can be written in the circular buffer. When the RX TDM reads this value, it updates its Padding Type in the RX TDM Control Memory, then uses that value to pad from then on. The RX xxPCM Buffer Structure also contains an Invalid Byte Counter that counts, in ms, how long it has been since a valid byte was received, with a maximum value of FFh (255 ms). If the RX Channel Association Memory points to an HDLC Stream Buffer Structure in the RX TDM Control Memory, the information contained in that structure indicates the base address and size of the RX Circular Buffer associated to that HDLC stream, as well as the current read and write pointers to that circular buffer. If there is no data contained in the circular buffer, then an idle code will be sent onto the H.110 bus (either 7Eh in byte-framing or FFh in bit-framing). Otherwise, the next available byte in the circular buffer will be sent onto the bus. All HDLC framing has already been done by the packet disassembly module. The RX Channel Association Memory also has an AS (Associated Stream) bit that allows greater bandwidth on HDLC streams; this bit is identical in function to the one in the TX direction. When this bit is `1', the RX Channel Association Memory binds 2 time slots to the corresponding RX TDM Control Memory entry instead of 1. This increases the total capacity of the RX Data Path in HDLC mode to 2046 time slots. In this mode, the 2 time slots that are bound together are 2 adjacent H.110 streams (i.e. ct_d[0] and ct_d[1], during the same time slot). The even stream contains the data that is logically first. The format of the RX TDM Control Memory is the following:
Zarlink Semiconductor Inc.
121
MT92210
Data Sheet
B0000h B0008h B0010h B0018h B0020h B0028h B0030h B0038h B0040h
xxPCM Buffer 0 or HDLC Buffer 0 xxPCM Buffer 1 or HDLC Buffer 0 xxPCM Buffer 2 or HDLC Buffer 1 xxPCM Buffer 3 or HDLC Buffer 1 xxPCM Buffer 4 or HDLC Buffer 2 xxPCM Buffer 5 or HDLC Buffer 2 xxPCM Buffer 6 or HDLC Buffer 3 xxPCM Buffer 7 or HDLC Buffer 3 xxPCM Buffer 8 or HDLC Buffer 4
B1FF0h xxPCM Buffer 1022 or HDLC Buffer 511 B1FF8h xxPCM Buffer 1023 or HDLC Buffer 511
RX HDLC Stream Structure b 15 b14 b13 b12 b11 b10 b9 +0 +2 +4 +6 +8 +A +C +E RX Circular Buffer Read Pointer [15:0] HT b8 b7 b6 b5 b4 b3 b2 b1 b0
RX Circular Buffer Base [20:8] / Size Indication RX Circular Buffer Write Pointer [15:0]
RX xxPCM Buffer Structure b 15 b14 b13 b12 b11 b10 b9 +0 +2 +4 +6 IL N OL b8 b7 b6 b5 b4 b3 b2 b1 b0
RX Circular Buffer Base [20:8] / Size Indication Invalid Byte Counter [7:0] Padding Type
Figure 67 - RX TDM Control Memory
122
Zarlink Semiconductor Inc.
Data Sheet
Field
IL OL RX Circular Buffer Base / Size Indication N Invalid Byte Counter: Padding Type
MT92210
Description
In law. Determines the PCM law for samples read from the RX Circular Buffer. `0' = u-law; `1' = A-law. Out law. Determines the PCM law for samples written to the TDM bus. `0' = u-law; `1' = A-law. This field indicates the size and base address of the circular buffer whose values must be output on the TDM bus. For xxPCM buffers, the size range is 256 bytes to 4K bytes. For HDLC streams, the size range is from 256 byte to 64K bytes. Nibble mode. `0' = ADPCM nibbles in high bits; `1' = ADPCM nibbles in low bits. Counter in ms during which no valid bytes have been received. This counter will be preset to FFh any time a CN packet is received. This counter is sticky at FFh. This field indicates what to output on the bus when underruns occur. It can be updated dynamically through the reception of CN packet. 0-63 = SSRAM Tone Buffers; 64-95 = SDRAM Silence Buffers; 96-123 = single padding octets; 124-127 = free-running time stamp counter, with MSB selected with value 124. The free-running time stamp counter can be used to generate a time stamp for multiple chips on the same TDM bus to be time stamp synchronized. HDLC Type. `0' = bit wise packet framing and escape code; `1' = byte wise packet framing and escape code. Copy of the write pointer contained in the RX HDLC Stream/Buffer Control Table. This pointer is used to determine how many bytes are valid in the circular buffer. RX HDLC Stream/Buffer Control Entries are associated with RX HDLC Stream Structures via direct implicit addressing (i.e. HDLC Stream # == RX HDLC Stream/Buffer Control Entry #). Address at which the next byte to be sent out on the HDLC stream will be read from in the RX Circular Buffer. This field is written to the RX HDLC Stream/Buffer Control Entries each time it is modified.
HT RX Circular Buffer Write Pointer
RX Circular Buffer Read Pointer
Table 45 - Fields and Description
Zarlink Semiconductor Inc.
123
MT92210
b13 b12 b11 b10 b9 256 Byte Buffer b8 b7 b6 b5 b4 b3 b2 b1 b0 1 b3 b2 b1 1 b4 b3 b2 1 b4 b3 1 b5 b4 1 b5 1 b6 1 b7 1 b8 1 b7 0 b6 0 b6 0 b5 0 b5 0 b5 0 b4 0 b4 0 b4 0 b4 0 b3 0 b3 0 b3 0 b3 0 b3 0 b2 0 b2 0 b2 0 b2 0 b2 0 b2 0 b1 0 b1 0 b1 0 b1 0 b1 0 b1 0 b1 0 b0 0 b0 0 b0 0 b0 0 b0 0 b0 0 b0 0 b0 0
Data Sheet
RX Circular Buffer Base [20:8] b13 b12 b11 b10 b9 b8 b7 b6 b5 b4
512 Byte Buffer
RX Circular Buffer Base [20:9] b13 b12 b11 b10 b9 b8 b7 b6 b5
1K Byte Buffer
RX Circular Buffer Base [20:10] b13 b12 b11 b10 b9 b8 b7 b6 b5
2K Byte Buffer
RX Circular Buffer Base [20:11] b13 b12 b11 b10 b9 b8 b7 b6
4K Byte Buffer
RX Circular Buffer Base [20:12] b13 b12 b11 b10 b9 b8 b7 b6
8K Byte Buffer *
RX Circular Buffer Base [20:13] b13 b12 b11 b10 b9 b8 b7
16K Byte Buffer *
RX Circ. Buffer Base [20:14] b13 b12 b11 b10 b9 b8
32K Byte Buffer *
RX Circ Buffer Base [20:15] b13 b12 b11 b10 b9
64K Byte Buffer *
RX Circ Buf Base [20:16]
* Note: Valid for HDLC Buffer only
Figure 68 - RX Circular Buffer Base/Size Indication
Each RX HDLC stream structure in the RX TDM Control Memory corresponds to an entry in the RX HDLC Stream/Buffer Control Table. This entry contains almost the same information as the RX HDLC stream structure, but is updated first by the packet disassembly module. When the RX HDLC stream structure thinks its circular buffer is empty, it checks the write pointer in the RX HDLC Stream/Buffer Control entry to see if it has changed since last time. Similarly, when the RX TDM process completes a packet, it updates the value of the read pointer in the RX HDLC Stream/Buffer Control entry.
124
Zarlink Semiconductor Inc.
Data Sheet
The format of the RX HDLC Stream/Buffer Control Table is the following:
MT92210
0000h 0008h
Entry 0 Entry 1
0FFCh 0FFEh
Entry 510 Entry 511 The RX HDLC Stream/Buffer Control Table is at a fixed address in SSRAM B. It always contains 512 entries.
RX HDLC Stream/Buffer Control Entry b 15 b14 b13 b12 b11 b10 b9 b8 b7 +0h +2h +4h +6h
b6
b5
b4
b3
b2
b1
b0
RX Circular Buffer Base [20:8] and Size Circular Buffer Write Pointer [15:0] Circular Buffer Read Pointer [15:0]
Figure 69 - RX HDLC Stream/Buffer Control Table Field
RX Circular Buffer Base and Size Circular Buffer Write Pointer Circular Buffer Read Pointer
Description
This field indicates the location and the size of the buffer that it used to store packets prior to sending them on this HDLC stream. Supported size are between 256 bytes and 64K bytes in step of 2^k. This pointer is used to remember the position of the next byte to be written in the circular buffer. It thus points to an invalid byte. The pointer is defined as a pointer to bytes. This field should be initialized to zero upon buffer creation. This pointer is used to remember the position of the next byte to be read in the circular buffer. It thus points to a valid byte. The pointer is defined as a pointer to bytes. When the read and write pointers are equal, the buffer is deemed empty. This field should be initialized to zero upon buffer creation. Packets in the HDLC Circular Buffers have already been zero inserted/byte inserted.
Note
Table 46 - Fields and Description
Zarlink Semiconductor Inc.
125
MT92210
b13 b12 b11 b10 b9 256 bytes: b8 b7 b6 b5 b4 b3 b2 b1 b0 1 b3 b2 b1 1 b4 b3 b2 1 b4 b3 1 b5 b4 1 b5 1 b6 1 b6 0 b6 0 b5 0 b5 0 b5 0 b4 0 b4 0 b4 0 b4 0 b3 0 b3 0 b3 0 b3 0 b3 0 b2 0 b2 0 b2 0 b2 0 b2 0 b2 0 b1 0 b1 0 b1 0 b1 0 b1 0 b1 0 b1 0 b0 0 b0 0 b0 0 b0 0 b0 0 b0 0 b0 0 b0 0
Data Sheet
RX Circular Buffer Base [20:8] b13 b12 b11 b10 b9 b8 b7 b6 b5 b4
512 bytes:
RX Circular Buffer Base [20:9] b13 b12 b11 b10 b9 b8 b7 b6 b5
1K bytes:
RX Circular Buffer Base [20:10] b13 b12 b11 b10 b9 b8 b7 b6 b5
2K bytes:
RX Circular Buffer Base [20:11] b13 b12 b11 b10 b9 b8 b7 b6
4K bytes:
RX Circular Buffer Base [20:12] b13 b12 b11 b10 b9 b8 b7 b6
8K bytes:
RX Circular Buffer Base [20:13] b13 b12 b11 b10 b9 b8 b7
16K bytes:
RX Circular Buffer Base [20:14] b13 b12 b11 b10 b9 b8 b7 1 b7 0
32K bytes:
RX Circular Buffer Base [20:15] b13 b12 b11 b10 b9 b8 1
64K bytes:
RX Circ Buf Base [20:16]
Figure 70 - RX Circular Buffer Base and Size
9.3.1
RX TDM Data Formats
When interfacing with external compression or silence suppression agents in xxPCM, the MT92210 uses special data formats that allow it to pass more than payload information over the H.110 bus. When transmitting ADPCM data, the position of the highest `1' in the data sample indicates the type of compression used: in this way, all ADPCM compression types can be encoded within a single payload byte. In addition, one extra piece of information can be passed to an off-chip ADPCM decompression agent: an ADPCM reset flag. This flag is set on the first byte following a silence period and it indicates to the ADPCM decompression agent to reset the ADPCM transcoder to default values. This is a requirement after silence periods because no ADPCM data has been sent during the silence period, causing the compression and decompression agents to be out of sync. One solution to this problem is to reset both at the beginning of valid voice. The implicit compression type as well as the ADPCM reset flag can be coded within an 8-bit sample. The ADCPM sample may also be contained in the high bits of the byte: in this case, the decoding is reversed, the position of the lowest `1' in the data sample indicates the compression type. An extra time slot is needed to encode PCM values along with the ADPCM values. If the compression rate can change to PCM as well as ADPCM, then 512 new values appear: 256 PCM values, and 256 PCM values with a reset flag. Despite the data being PCM, the ADPCM decompression agent may use it to synchronize its CODEC during the period of time where the data is PCM, so that if the decompression rate reverts to ADPCM, its context is valid. Therefore 2 extra bits on an associated stream are used. The RX TDM is also capable of passing spectral CN packets on the H.110 bus. The encoding of these packets is done by passing 80h on the bus as a header, followed by the packet and trailed by a 16-bit CRC for data integrity purposes. When spectral CN packets are used, no padding is inserted by the chip: invalid bytes are indicated by a 00h code on the bus.
126
Zarlink Semiconductor Inc.
Data Sheet
The format of the RX xxPCM TSSTs is the following:
TSST Grouping on H.110 (with Associated Stream Enabled) b7 TSST0 TSST1 b6 b5 b4 b3 b2 b1 b0 PCM-R 1 0 b7
MT92210
Format of PCM Samples (both padding and voice) (no Decompressor Reset) b6 b5 b4 b3 b2 b1 b0
PCM-R
Reserved RX xxPCM Sample
PCM Sample
TSST Grouping on H.110 (with Associated Stream Disabled) b7 TSST0 b6 b5 b4 b3 b2 b1 b0 PCM-R 1 1
Format of PCM Samples (both padding and voice) (with Decompressor Reset) b7 b6 b5 b4 b3 b2 b1 b0
RX xxPCM Sample
PCM Sample
RX Code Point Format Format of ADPCM Samples in low bits (with Decompressor reset) PCM-R 0 0 b7 1 b7 1 b7 1 b7 1 b6 0 b6 0 b6 0 b6 0 b5 1 b5 0 b5 0 b5 0 b4 b3 b2 b1 b0 Format of ADPCM Samples in low bits (no Decompressor reset) PCM-R 0 b0 0 b7 0 b7 0 b7 0 b7 0 b6 0 b6 0 b6 0 b6 0 b5 1 b5 0 b5 0 b5 0 b4 b3 b2 b1 b0
ADPCM 40kbps b4 1 b4 0 b4 0 b3 1 b3 0 b2 1 b3 b2 b1
ADPCM 40kbps b4 1 b4 0 b4 0 b3 1 b3 0 b2 1 b3 b2 b1 b0
PCM-R 0 0
PCM-R 0 0
32kbps b2 b1 b0
32kbps b2 b1 b0
PCM-R 0 0
PCM-R 0 0
24kbps b1 b0
24kbps b1 b0
PCM-R 0 0
PCM-R 0 0
16kbps
16kbps
Format of ADPCM Samples in high bits (with Decompressor reset) PCM-R 0 0 b7 b7 b6 b5 b4 b3 b2 1 b3 1 b4 1 b5 1 b4 0 b3 0 b3 0 b2 0 b2 0 b2 0 b1 0 b1 0 b1 0 b1 0 b0 1 b0 1 b0 1 b0 1
Format of ADPCM Samples in high bits (no Decompressor reset) PCM-R 0 0 b7 b7 b6 b5 b4 b3 b2 1 b3 1 b4 1 b5 1 b4 0 b3 0 b3 0 b2 0 b2 0 b2 0 b1 0 b1 0 b1 0 b1 0 b0 0 b0 0 b0 0 b0 0
ADPCM 40kbps b6 b5 b4
ADPCM 40kbps b6 b5 b4
PCM-R 0 0
PCM-R 0 0
32kbps b7 b6 24kbps b7 b6 b5
32kbps b7 b6 24kbps b7 b6 b5
PCM-R 0 0
PCM-R 0 0
PCM-R 0 0
PCM-R 0 0
16kbps
16kbps
Figure 71 - Format of RX xxPCM TSSTs - 1 of 2
Zarlink Semiconductor Inc.
127
MT92210
Spectral CN Packet Spectral CN/SID Packet (ADPCM Samples in high bits)
PCM-R 0 1 1 1 0 0 0 0 b7 1 b6 0 b5 0 b4 0 b3 0 b2 0 b1 0 b0 0
Data Sheet
CN/SID Payload Length [7:0] CN CN/SID Payload Byte 0 [7:0] CN CN/SID Payload Byte 1 [7:0] CN Fields covered by CRC16 (PCM-R not included in CRC16)
1 1 1 1 0 0
0 0 0 0 0 0 0 0
CN/SID Payload Byte N-2 [7:0] CN CN/SID Payload Byte N-1 [7:0] CN CRC16 [15:8] CRC16 [7:0] 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Explicit Underrun Indication (present until another CN/voice packet is received)
0 0
0 0
0 0
0 0
0 0
0 0
0 0
0 0
0 0
0 0
Spectral CN Packet Spectral CN/SID Packet (ADPCM Samples in low bits)
PCM-R 0 1 1 1 0 0 0 0 b7 0 b6 0 b5 0 b4 0 b3 0 b2 0 b1 0 b0 1
CN CN/SID Payload Length [7:0]
CN/SID Payload Byte 0 [7:0] CN CN/SID Payload Byte 1 [7:0] CN
1 1 1 1 0 0
0 0 0 0 0 0 0 0
CN/SID Payload Byte N-2 [7:0] CN CN/SID Payload Byte N-1 [7:0] CN CRC16 [15:8] CRC16 [7:0] 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0
0 0
0 0
0 0
0 0
0 0
0 0
0 0
0 0
0 0
Figure 72 - Format of RX xxPCM TSSTs - 2 of 2
Two lookup tables are used to determine padding bytes during a silence period based on the received CN packet. The following CN Lookup Table is located at fixed address in SSRAM B:
128
Zarlink Semiconductor Inc.
Data Sheet
b 15 b14 b13 b12 b11 b10 b9 2000h 2002h CN=0 Padding Type CN=2 Padding Type b8 b7 b6 b5 b4 b3 b2 b1 b0
MT92210
CN=1 Padding Type CN=3 Padding Type
20FCh 20FEh
CN=252 Padding Type CN=254 Padding Type
CN=253 Padding Type CN=255 Padding Type
Figure 73 - CN Packet Conversion Lookup Table Field
Padding Type
Description
This field indicates the padding type that should be placed on the TDM bus during this silence period. The first byte of the CN packet is used as an index into this table. 128-191 = SSRAM Tone Buffers; 192-223 = SDRAM Silence Buffers; 224-251 = Padding Octets; 252-254 = Reserved; 255 = Ignore CN Packet.
Table 47 - Fields and Description
Zarlink Semiconductor Inc.
129
MT92210
Data Sheet
130
Zarlink Semiconductor Inc.
Data Sheet
10.0 H.110 Interface
MT92210
The TDM interface on the MT92210 device is fully compatible with the H.110 bus and can be used to interface either as bus master or as bus slave. It respects all of the major requirements of H.110, such as supporting up to 32 TDM streams running at 8 MHz (up to 4096 time slots), the possibility of running 16 of the streams at lower frequencies (2 or 4 MHz), and the capability of passing 128 of the channels on H.110 in loopback. The slave portion of the H.110 interface respects the timing requirements of this interface. It can sample the incoming data from the ct_d pins 90 ns after the rising edge of the clock as per the spec (3/4 sampling), and it can also sample on the falling edge (2/4 sampling) or rising edge of the clock (4/4 sampling). When driving its data, it can tri-state its pins early (between 20 and 0 ns before the rising edge of the clock) or it can tri-state synchronously on the rising edge of the clock. Both of these options allow flexibility in interoperation with other devices that are not fully H.110 compliant.
ct_c8 ct_frame ct_d_out (8M) ct_d_out (4M) ct_d_out (2M) ct_d_out (8M,ealry Z) ct_d_out (4M,ealry Z) ct_d_out (2M,ealry Z) ct_d_in (8M) ct_d_in (4M) ct_d_in (2M) 127.b6 127.b5 127.b4 127.b3 127.b2 127.b1 127.b0 63.b3 31.b1 63.b2 63.b1 31.b0 63.b0
127.b6 127.b5 127.b4 127.b3 127.b2 127.b1 127.b0 63.b3 31.b1 63.b2 63.b1 31.b0 63.b0
1/2 Period Sampling 3/4 Period Sampling 4/4 Period Sampling
Figure 74 - TDM Bus Timing - ct_d
10.1
Slave Mode
When operating as a slave, the interface has the choice between clocking on A, clocking on B, clocking on A with B as backup or clocking on B with A as backup. When set to perform automatic switchover, the interface monitors the current bus master to see if its ct_c8 and ct_frame signals are still valid. The ct_c8 signal is checked to see if its clock edges are within 35 ns of where they are supposed to be (122 ns apart). The ct_frame signal is checked to make sure that it occurs exactly once every 1024 ct_c8 clock cycles. If either of these two errors is reported about a given pair of bus master signals, the pair is considered invalid and the slave will switch to the backup master if any has been programmed to do so. The MT92210 will always monitor these signals and report errors on either of the two bus masters, even if it does not act on these errors.
10.2
Bus Master Mode
When acting as a bus master, the MT92210 can choose to be a bus master on A, master on B, backup on A or backup on B. When acting as a bus backup, the MT92210 uses the same error signals described above to determine if the current bus master is still valid or if it should take over the bus. Note that the bus mastership can be overridden in registers by ensuring that the chip cannot drive the H.110 clock and frame signals: this will ensure that it remains a passive slave on the bus. If the chip is a backup on the bus and the primary master fails, it will stop synchronizing itself on the master and track the local reference.
Zarlink Semiconductor Inc.
131
MT92210
ct_c8 ct_frame fr_comp (8M,Strdl) fr_comp (4M,Strdl) fr_comp (2M,Strdl) fr_comp (8M,Last) fr_comp (4M,Last) fr_comp (2M,Last) fr_comp (8M,First) fr_comp (4M,First) fr_comp (2M,First) Note: The fr_comp polarity in this drawing is always active low for simplicity. It can also be programmed active high.
Data Sheet
Figure 75 - TDM Bus Timing - fr_comp Generation
The chip can also control all the compatibility clocks that must be generated on H.110. There are a good number of these signals and their generation is independent of the mastership on either A or B: the chip can choose to generate all of these, or not, whether or not it is bus master or backup. Because these compatibility signals are, by definition, used to meet the specific requirements of an older bus standard, their generation is not programmable for the most part.
ct_c8 ct_frame sclkx2 (8M) sclkx2 (8M, inverted) sclk (8M) sclk (8M, inverted) sclkx2 (4M) sclkx2 (4M, inverted) sclk (4M) sclk (4M, inverted) sclkx2 (2M) sclkx2 (2M, inverted) sclk (2M) sclk (2M, inverted)
Figure 76 - TDM Bus Timing - sclkx2 Generation
ct_c8 ct_frame c16+ c16c2 c4
:
Figure 77 - TDM Bus Timing - Compatibility Clock Generation (other than sclk, sclkx2)
132
Zarlink Semiconductor Inc.
Data Sheet
10.3 Polarities
MT92210
There are a few exceptions, however. The sclk and sclkx2 signals can be programmed to have their polarities identical to those defined in the H.110 specification, or they can have the opposite polarity. In some cases their rising edges will coincide with the rising edge of ct_c8, and in some cases will coincide with falling edges. In addition, the frequency of sclk can be programmed to 2, 4 or 8 MHz, with sclkx2 being generated in function of this (note that when sclk is 8 MHz, sclkx2 is also 8 MHz but off-shifted by a quarter-period. For more details on expected polarity, see H.110 specification). The fr_comp signal can also be generated active-high or active-low, can be generated as coinciding with a clock edge or as straddling it, and can be generated as relating to a clock at 2 MHz, 4 MHz or 8 MHz. As mentioned earlier, H.110 requires that the lower 16 streams on the bus be capable of running at 2 or 4 MHz, with a single clock frequency determined for each group of 4 streams. The MT92210 allows every group of 4 streams on the bus to operate at 2, 4 or 8 MHz, allowing all 32 streams to be used in backwards compatibility with another non-H.110 agent. In addition, the MT92210, instead of supporting the full bandwidth of H.110, can be configured to only interface with 4, 8 or 16 of the streams on the bus. This allows the chip to be run at a much lower frequency than 60 MHz.
Zarlink Semiconductor Inc.
133
MT92210
Data Sheet
134
Zarlink Semiconductor Inc.
Data Sheet
11.0 Clocking
MT92210
The MT92210 has 2 main clock domains: mem_clk_net and mem_clk_sar. They are used for the Network Interface and the SAR portion of the device accordingly. These clocks can be sourced externally or created internally using PLLs.
11.1
Programming the mem_clk_xxx PLL
The clock multiplication PLLs in the MT92210 are used to take a low frequency upclk, always provided on the upclk pin, and multiply it up to the fast_clk frequency. There, it is divided down to the mem_clk_xxx frequency. The X, Y and Z divider can be programmed to any legal value through registers 164h or 166h (as defined in the tables below). upclk can be fed into the device with a frequency ranging from 25 MHz to 66 MHz. Only frequencies between 50 MHz and 53.3 MHz are not supported by the PLL. The X and Y divisor tables indicate what values to program in the X,Y and Z registers depending on the input value of upclk. The Z divisor table indicates the range of mem_clk_xxx that can be achieved with typical values of Z. Note that mem_clk_xxx cannot be programmed above 100 MHz or below 40 MHz. fast_clk is used by the TDM interface and must operate between 160 MHz to 200 MHz. The mem_clk_xxx PLL drives the output mem_clk_xxx pins. These pins provide both TTL and PECL interfaces for mem_clk_xxx input and output. For both types, the output pins for mem_clk_xxx is always driven. However, when the output pins are not being used, the register bits that control the toggling of these 2 pins should be disabled to reduce power consumption. The user must configure the MT92210 to select the desired mem_clk_xxx input type, either PECL or TTL. mem_clk_xxx serves as the main clock for the chip and therefore must be present for the MT92210 to function. It is absolutely necessary for mem_clk_xxx to be present and one of the inputs to be selected. The mem_clk_xxx outputs however, are simply a convenience for the user and do not require to be connected. These outputs eliminate the need for a second, high-speed oscillator. The user need only generate upclk. The clock that is connected to the mem_clk_xxx inputs on the MT92210, whether it is TTL or PECL, must be in phase with the clock connected to SSRAM used with the chip. The maximum skew allowed is 0.5 ns.
.
Div X
1 1 2 2 6 5 8 6
Div Y
upclk (MHz)
0 to 30 30 to 33.33 33.33 to 40 40 to 50 50 to 53.33 53.33 to 66.66 -
fast_clk (MHz)
160 to 200 166.66 to 200 160 to 200 160 to 200
Table 48 - Clock Divisor X and Y
Zarlink Semiconductor Inc.
135
MT92210
Data Sheet
Div Z
2 3 4 5* 6* 7* 8* 9* 10* 12* 14* 16*
Mem_clk_xxx
80 to 100 53.3 to 66.6 40 to 50 32 to 40 26.6 to 33.3 22.8 to 28.6 20 to 25 17.8 to 22.2 16 to 20 13.3 to 16.6 11.4 to 14.3 10 to 12.5
* These values of Z should not be used.
Table 49 - Clock Divisor Z
upclk mem_clk_sar_i mem_clk_net_i Clock Divisor x = 1 to 15 REF CKOUT fc1pll FB
Clock Divisor mem_clk_sar_o z = 1 to 15
fast_clk Clock Divisor y = 1 to 15
upclk mem_clk_sar_i mem_clk_net_i Clock Divisor x = 1 to 15 REF fc2pll FB CKOUT
Clock Divisor mem_clk_net_o z = 1 to 15
Clock Divisor y = 1 to 15
Figure 78 - Clock Synthesis
136
Zarlink Semiconductor Inc.
Data Sheet
11.2 Clock Recovery
MT92210
Since the MT92210 interfaces with a TDM bus, it is necessary that it incorporate a clock recovery circuit that will allow it to generate a precise TDM clock. As such, the MT92210 contains data gathering hardware to accumulate information concerning timing VCs or channels, as well as clock generation mechanisms. The first portion of the clock recovery is a point gathering system that feeds software with all the information it needs to obtain a very precise measurement of the clock it needs to generate. The module receives pulses obtained either from the UTOPIA module (timing reference VCs) or from the RTP RX SAR (timing reference packets). These pulses can then be filtered, so that only a single pulse out of N is actually kept and treated by the hardware: this artificially "slows down" the timing reference signal by a factor of N. In parallel, free running counters of mem_clk and of the adap_ref signal are kept, giving a very good idea of the time at which each pulse is received. When a pulse is kept by the filtering algorithm, a clock recovery event structure is written to external memory, with the 32-bit mem_clk counter, the 32-bit adap_ref counter and a 16-bit fraction of the adap_ref counter, as well as the LI and UUI of the received mini-packet. These event structures are written to a buffer in external memory, and the clock recovery module will generate an interrupt when the buffer is more than half full. Because clock recovery events arrive at a fixed rate, the size of the buffer chosen will completely determine the rate at which it needs to be serviced.
+0 +10
E vent 0 E vent 1
+(N-2)*10h +(N-1)*10h
E vent N-2 E vent N-1
Figure 79 - Adaptive Clock Recovery Event Queue
The Adaptive Clock Recovery Event Queue is a circular buffer in SSRAM A used to report packet reception events to the host processor. It can be programmed to sizes of 4K bytes to 128K bytes in steps of 2^k. It must be mapped on a base address of its size. The position and size of this queue can be programmed at register address 0xB20 and 0xB28, for queue A and B respectively.
b15 b14 b13 b12 b11 b10 b9 +0 +2 +4 +6 +8 +A +C +E
b8
b7
b6
b5
b4
b3
b2
b1
b0
mem_clk_sar_i Counter [31:16] mem_clk_sar_i Counter [15:0] Reference Clock Counter [31:16] Reference Clock Counter [15:0] mem_clk_sar_i Cycles Since Last Reference Clock Rise [15:0] RTP Sequence Number [15:0] RTP Timestamp [31:16] R Ti est am p [ 15: 0] TP m
Figure 80 - Adaptive Clock Recovery RTP Event Structure
Zarlink Semiconductor Inc.
137
MT92210
Field
mem_clk_sar_i Counter
Data Sheet
Description
When an Adaptive Clock Recovery RTP Event Structure is generated, the mem_clk_sar_i free-running counter (the same one as in registers 908h and 90Ah) is sampled and written in this structure. When an Adaptive Clock Recovery RTP Event Structure is generated, the free-running counter that counts the rising edges of the clock generator A module will be sampled and written in this structure. When the Reference Clock Counter increments infrequently (i.e. the generate clock is low in frequency) this field can be used to approximate the fraction of a Reference Clock Cycle that can be appended to the Reference Clock Counter. This field in defined as the number of mem_clk_sar_i cycles that elapsed since the last increment of the Reference Clock Counter. Sequence number of the packet that caused this Adaptive Clock Recovery Event Structure to be written. Timestamp of the packet that caused this Adaptive Clock Recovery Event Structure to be written.
Reference Clock Counter mem_clk_sar_i Cycles Since Last Reference Clock Rise
RTP Sequence Number RTP Timestamp
Table 50 - Fields and Description
138
Zarlink Semiconductor Inc.
Data Sheet
vc_reference_a gpio_in[0] mem_clk
MT92210
Keep One Pulse Out of X (Range=1-1024) 32 bit freerunning mem_clk counter 16 bit mclk count since last ref rising edge 32 bit freerunning ref rising edge counter
E 80 bit Super-Structure
Written to clock recovery buffer in external memory bank A
mem_clk
Programmable Fractional Divisor (Range = 2 to 65535)
adapa_ref
vc_reference_b gpio_in[1] mem_clk
Keep One Pulse Out of X (Range=1-1024) 32 bit free running mem_clk counter 16 bit mclk count since last ref rising edge 32 bit free running ref rising edge counter
E 80 bit Super-Structure
Written to clock recovery buffer in external memory bank A
mem_clk
Programmable Fractional Divisor (Range = 2 to65535)
adapb_ref
Figure 81 - Adaptive Clock Recovery Modules
Zarlink Semiconductor Inc.
139
MT92210
Data Sheet
The second portion of the clock recovery circuit is concerned with actually generating the adap_ref signal. When software reads the information placed in the buffer, it can calculate what is the rate of the clock that needs to be generated. The generated clock is always mem_clk divided by a 16-bit integer and 16-bit fraction, which allows a very high precision on the division (with mem_clk running at 50 MHz and a target clock speed of 8 kHz, it gives a precision of 0.4 ppb). Software can program the integer and fraction by which it desires mem_clk to be divided by, and the division will be performed in hardware. The adap_ref signal can then be output onto any of a number of GPIOs on the chip, or to one of the ct_netrefs: among other uses, it can be routed to an external PLL used to multiply it up from 8 kHz to 16 MHz and then rerouted into the chip on the pll_clk pin.
ct_c8_a ct_c8_b ct_frame_a ct_frame_b `0'/'1' ct_c8_selected ct_frame_selected ct_netref1_in ct_netref2_in gpio_in[0] gpio_in[1] gpio_in[2] gpio_in[3] gpio_in[4] gpio_in[5] gpio_in[6] gpio_in[7] adapa_ref adapb_ref vc_reference_a vc_reference_b mc_clock ct_mc_in Pll_clk
M U X
Edges and Level Monitor
gpio[7:0], ct_netref1, ct_netref2 Internal_pll_clk
Figure 82 - GPIO Functionality
140
Zarlink Semiconductor Inc.
Data Sheet
MT92210
gpio_in[2]
`0' ct_mc_in ct_mc
ct_c8_selected ct_frame_selected
MC Clock Generator
mc_clock
Figure 83 - Message Channel Circuit
11.3
Memory Controllers
The MT92210 uses 3 separate memory banks, each with its own memory controller. Memory bank A is used for structures in the TX direction. Memory bank B is used for structures in the RX direction. Memory bank C is used by the device's network interface. Each memory bank, A, B or C, can connect up to 4 external SSRAM chips, each ranging in size from 128K to 1M bytes. However, the total size of SSRAM chips on each bank is limited to 2M bytes. Memory bank C can also connect to one external SDRAM of either 16M or 32M bytes. Memory banks A and B are 16 bits wide, while bank C is 32 bits wide. Because SDRAM devices are much more commonly found in 16-bit configuration, 2 devices can be placed side by side. On memory bank C, the address and data pins are shared between the SSRAM and SDRAM devices. SSRAM must be pipelined or flow-through ZBT (Zero-Bus Turnaround) type memory. To multiplex the accesses that all agents require of these memories, memory controllers are used. Each memory controller grants the memory bus to the various agents within the chip, using a priority algorithm to make sure that the agents that need the memory most urgently get it, and transforming these memory accesses into the correct pin signals depending on the configuration of the memories. The memory controller is responsible for generating even parity on the parity pins of the memories and detecting that the parity is correctly received when data is read from the memory. To do so, it calculates even parity on all the address bits and data bits used to generate each access. When reading from the memory, it performs the same calculation in the opposite direction. Any errors in parity are reported to registers. To render parity generation and detection more powerful, masks can be used, causing the memory controller to only calculate parity on some bits. These masks are programmed in registers 230h to 234h. Parity is calculated on all locations in memory except for the reception circular buffers, in which the parity bits are used for underrun information. It is possible to override this and use parity even on these circular buffers through control bits in registers. The controller also makes sure that the SDRAMs used are refreshed often enough so as to ensure that data in them is never corrupted. The refresh period is indicated in registers, and a limit value is placed on how far behind in its refreshing the chip can afford to be. If the refresh mechanism falls behind by more than this number, a status error will be reported. This is programmed in registers 398h and 39Ah. Finally, the memory controller allows manual accesses to the SDRAM to be performed through registers, allowing CPU accesses to perform the initialization sequence to the SDRAM.
Zarlink Semiconductor Inc.
141
MT92210
Data Sheet
142
Zarlink Semiconductor Inc.
Data Sheet
12.0 Pin-out
MT92210
The following list describes the pin-out of the MT92210 device. Some pins have multiple functions, however, each pin bears the name of its principal function. All outputs are 3.3 V outputs only. Pins identified with (F) in Type tolerate 5V for inputs and outputs. All pins are tested with 50 pf of load, unless otherwise specified.
Pin Description Table
SIGNAL Name Nom Switch (MHz) Description WC Switch (MHz) Interface
Reset
A14 A19 C20 B18 D19 T1 P1 N1 P2 P5 M1 M3 N2 N5 N4 K4 M2 K1 L3 J4 R3 R4 R2 R1 T2 AA4 Y2 AB1 W5 W3
upclk cpu_mode[0] cpu_mode[1] cpu_mode[2] cpu_mode[3] cpu_a[0] cpu_a[1] cpu_a[2] cpu_a[3] cpu_a[4] cpu_a[5] cpu_a[6] cpu_a[7] cpu_a[8] cpu_a[9] cpu_a[10] cpu_a[11] cpu_a[12] cpu_a[13] cpu_a[14] cpu_wr_rw cpu_rd_ds cpu_ale cpu_a_das cpu_cs cpu_d[0] cpu_d[1] cpu_d[2] cpu_d[3] cpu_d[4]
CPU CPU CPU CPU CPU CPU CPU CPU CPU CPU CPU CPU CPU CPU CPU CPU CPU CPU CPU CPU CPU CPU CPU CPU CPU CPU CPU CPU CPU CPU 12.5 12.5 12.5 12.5 12.5 12.5 12.5 25 25 25 25 25 25 25
I I I I I I I I I I I I I I I I I I I I I I I I/O I/O I/O I/O I/O I/O I/O Z Z Z Z Z Z
LVTTL (F) LVTTL LVTTL LVTTL LVTTL LVTTL (F) LVTTL (F) LVTTL (F) LVTTL (F) LVTTL (F) LVTTL (F) LVTTL (F) LVTTL (F) LVTTL (F) LVTTL (F) LVTTL (F) LVTTL (F) LVTTL (F) LVTTL (F) LVTTL (F) LVTTL (F) LVTTL (F) LVTTL (F) LVTTL 4 mA (F) LVTTL 4 mA (F) LVTTL 4 mA (F) LVTTL 4 mA (F) LVTTL 4 mA (F) LVTTL 4 mA (F) LVTTL 4 mA (F)
Zarlink Semiconductor Inc.
Type
Pull
Pin
I/O
143
MT92210
Pin Description Table (continued)
SIGNAL Name Nom Switch (MHz)
Data Sheet
W2 V4 U5 V5 V2 W1 V1 T3 T4 U1 U2 T5 Y5 W4 AD2 AC1 AG2 AG1 AD4 AD5 AH2
cpu_d[5] cpu_d[6] cpu_d[7] cpu_d[8] cpu_d[9] cpu_d[10] cpu_d[11] cpu_d[12] cpu_d[13] cpu_d[14] cpu_d[15] cpu_rdy_ndtack cpu_int[0] cpu_int[1] ct_c8_a ct_c8_b ct_frame_a ct_frame_b ct_netref1 ct_netref2 ct_mc
CPU CPU CPU CPU CPU CPU CPU CPU CPU CPU CPU CPU CPU CPU H110 H110 H110 H110 H110 H110 H110
12.5 12.5 12.5 12.5 12.5 12.5 12.5 12.5 12.5 12.5 12.5 12.5
25 25 25 25 25 25 25 25 25 25 25 25
I/O I/O I/O I/O I/O I/O I/O I/O I/O I/O I/O I/O O O
Z Z Z Z Z Z Z Z Z Z Z Z Z Z Z Z Z Z Z Z Z U U U
LVTTL 4 mA (F) LVTTL 4 mA (F) LVTTL 4 mA (F) LVTTL 4 mA (F) LVTTL 4 mA (F) LVTTL 4 mA (F) LVTTL 4 mA (F) LVTTL 4 mA (F) LVTTL 4 mA (F) LVTTL 4 mA (F) LVTTL 4 mA (F) LVTTL 8 mA (F) LVTTL 4 mA (F) LVTTL 4 mA (F) Schmitt 12 mA (F) Schmitt 12 mA (F) LVTTL 12 mA (F) LVTTL 12 mA (F) Schmitt 12 mA (F) Schmitt 12 mA (F) LVTTL 12 mA (F) 200 pf load 200 pf load 200 pf load 200 pf load 200 pf load 200 pf load If this pin is connected to the H110 bus, gpio[2] must be used to drive it. When reset is deasserted and ct_mc output enabled, gpio[2] low will cause ct_mc to be driven low. Otherwise it will be tri-stated. 200 pf load 200 pf load 200 pf load 200 pf load 200 pf load 200 pf load 200 pf load 200 pf load 200 pf load 200 pf load 200 pf load 200 pf load
8 8 1 1 2 2 1
8 8 1 1 2 2 2
I/O I/O I/O I/O I/O I/O I/O
AJ14 AJ13
ct_d[0] ct_d[1]
H110 H110 H110 H110 H110 H110 H110 H110 H110 H110 H110 H110
1 1 1 1 1 1 1 1 1 1 1 1
4 4 4 4 4 4 4 4 4 4 4 4
I/O I/O I/O I/O I/O I/O I/O I/O I/O I/O I/O I/O
Z Z Z Z Z Z Z Z Z Z Z Z
PCI (F) PCI (F) PCI (F) PCI (F) PCI (F) PCI (F) PCI (F) PCI (F) PCI (F) PCI (F) PCI (F) PCI (F)
AG13 ct_d[2] AK13 ct_d[3] AF14 AJ12 ct_d[4] ct_d[5]
AG10 ct_d[6] AK12 ct_d[7] AF13 AK11 AJ10 AJ11 ct_d[8] ct_d[9] ct_d[10] ct_d[11]
144
Zarlink Semiconductor Inc.
Description
WC Switch (MHz)
Interface
Reset
Type
Pull
Pin
I/O
Data Sheet
Pin Description Table (continued)
SIGNAL Name Nom Switch (MHz)
MT92210
AF10 AF12 AF11 AJ9 AK9 AH8 AF8 AG7 AG5 Ak7 AJ6 AF9 AK6 AJ5 AK8 AF7 AJ8 AK5 AJ7 AE1 AF2 AB2 AE2 AF5 AH1 AF4 T28 AB4 AC4 AA2 AC3 AA1 AA5 AC2 AB5 Y4 R28
ct_d[12] ct_d[13] ct_d[14] ct_d[15] ct_d[17] ct_d[18] ct_d[19] ct_d[20] ct_d[21] ct_d[22] ct_d[23] ct_d[24] ct_d[25] ct_d[26] ct_d[27] ct_d[28] ct_d[29] ct_d[30] ct_d[31] sclk sclkx2 c16p c16n c2 c4 frcomp nreset pll_clk gpio[0] gpio[1] gpio[2] gpio[3] gpio[4] gpio[5] gpio[6] gpio[7] trst
H110 H110 H110 H110 H110 H110 H110 H110 H110 H110 H110 H110 H110 H110 H110 H110 H110 H110 H110 H110 H110 H110 H110 H110 H110 H110 H110 MISC MISC MISC MISC MISC MISC MISC MISC MISC MISC Test
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 8 8 16 16 2 4 1
4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 8 8 16 16 2 4 1
I/O I/O I/O I/O I/O I/O I/O I/O I/O I/O I/O I/O I/O I/O I/O I/O I/O I/O I/O I/O O O O O O O O I I
Z Z Z Z Z Z Z Z Z Z Z Z Z Z Z Z Z Z Z Z Z Z Z Z Z Z Z
PCI (F) PCI (F) PCI (F) PCI (F) PCI (F) PCI (F) PCI (F) PCI (F) PCI (F) PCI (F) PCI (F) PCI (F) PCI (F) PCI (F) PCI (F) PCI (F) PCI (F) PCI (F) PCI (F) PCI (F) LVTTL 12 mA (F) LVTTL 12 mA (F) LVTTL 12 mA (F) LVTTL 12 mA (F) LVTTL 12 mA (F) LVTTL 12 mA (F) LVTTL 12 mA (F) LVTTL LVTTL (F)
200 pf load 200 pf load 200 pf load 200 pf load 200 pf load 200 pf load 200 pf load 200 pf load 200 pf load 200 pf load 200 pf load 200 pf load 200 pf load 200 pf load 200 pf load 200 pf load 200 pf load 200 pf load 200 pf load 200 pf load 200 pf load 200 pf load 200 pf load 200 pf load 200 pf load 200 pf load 200 pf load
AK10 ct_d[16]
16 16 16 16 16 16 16 16
16 16 16 16 16 16 16 16
I/O I/O I/O I/O I/O I/O I/O I/O I
Z Z Z Z Z Z Z Z D
LVTTL 4 mA (F) LVTTL 4 mA (F) LVTTL 4 mA (F) LVTTL 4 mA (F) LVTTL 4 mA (F) LVTTL 4 mA (F) LVTTL 4 mA (F) LVTTL 4 mA (F) LVTTL
Zarlink Semiconductor Inc.
Description
WC Switch (MHz)
Interface
Reset
Type
Pull
Pin
I/O
145
MT92210
Pin Description Table (continued)
SIGNAL Name Nom Switch (MHz)
Data Sheet
AF1 AD1 AF15 AE4 K30 AG3 AK4 AE5 F29 D18 L29 AJ24 L26 AJ23 Y30 G27 F30 J30 B26 H27 J26 E27 C27 A24 B25 D25 C28 D26 E30 D28 F27 K29 C24 E23 B21 D24
tck tdi tms tdo Icptn Manufacturing_t m proc_out txa_led rxa_led rxa_alarm mem_clk_sar_o mem_clk_net_o mem_clk_sar_i mem_clk_net_i mem_oe mema_cs[0] mema_cs[1] mema_cs[2] mema_cs[3] mema_rw mema_bws[0] mema_bws[1] mema_a[0] mema_a[1] mema_a[2] mema_a[3] mema_a[4] mema_a[5] mema_a[6] mema_a[7] mema_a[8] mema_a[9] mema_a[10] mema_a[11] mema_a[12] mema_a[13]
Test Test Test Test Test Test Test Test PORTA PORTA PORTA MEM MEM MEM MEM MEM MEMA MEMA MEMA MEMA MEMA MEMA MEMA MEMA MEMA MEMA MEMA MEMA MEMA MEMA MEMA MEMA MEMA MEMA MEMA MEMA MEMA 18.75 18.75 18.75 18.75 18.75 18.75 18.75 18.75 18.75 18.75 18.75 18.75 18.75 18.75 18.75 18.75 18.75 18.75 18.75 18.75 18.75 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 80 80 80 80
I I I O I I I O I/O I/O I O O I I O O O O O O O O O O O O O O O O O O O O O O 1 1 1 1 1 1 1 1 X X X X X X X X X X X X X X 0 0 X X D U D
LVTTL (F) LVTTL (F) LVTTL LVTTL 4 mA (F) LVTTL LVTTL LVTTL (F) LVTTL 4 mA LVTTL 8 mA (F) LVTTL 8 mA LVTTL (F) LVTTL 4 mA LVTTL 4 mA LVTTL LVTTL LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA
AH16 iddtn
146
Zarlink Semiconductor Inc.
Description
WC Switch (MHz)
Interface
Reset
Type
Pull
Pin
I/O
Data Sheet
Pin Description Table (continued)
SIGNAL Name Nom Switch (MHz)
MT92210
C23 A22 B20 H30 G28 E22 E24 A26 B24 D30 E29 H29 F26 E26 G26 C30 G30 B23 A23 B28 A25 G29 A28 N30 M27 P30 R27 T29 T27 U30 W27 U29 U26 T30 T26 R30 P29 R29
mema_a[14] mema_a[15] mema_a[16] mema_a[17] mema_a[18] mema_d[0] mema_d[1] mema_d[2] mema_d[3] mema_d[4] mema_d[5] mema_d[6] mema_d[7] mema_d[8] mema_d[9] mema_d[10] mema_d[11] mema_d[12] mema_d[13] mema_d[14] mema_d[15] mema_p[0] mema_p[1] memb_d[0] memb_d[1] memb_d[2] memb_d[3] memb_d[4] memb_d[5] memb_d[6] memb_d[7] memb_d[8] memb_d[9] memb_d[10] memb_d[11] memb_d[12] memb_d[13] memb_d[14]
MEMA MEMA MEMA MEMA MEMA MEMA MEMA MEMA MEMA MEMA MEMA MEMA MEMA MEMA MEMA MEMA MEMA MEMA MEMA MEMA MEMA MEMA MEMA MEMB MEMB MEMB MEMB MEMB MEMB MEMB MEMB MEMB MEMB MEMB MEMB MEMB MEMB MEMB
18.75 18.75 18.75 18.75 18.75 9.375 9.375 9.375 9.375 9.375 9.375 9.375 9.375 9.375 9.375 9.375 9.375 9.375 9.375 9.375 9.375 9.375 9.375 9.375 9.375 9.375 9.375 9.375 9.375 9.375 9.375 9.375 9.375 9.375 9.375 9.375 9.375 9.375
37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5
O O O O O I/O I/O I/O I/O I/O I/O I/O I/O I/O I/O I/O I/O I/O I/O I/O I/O I/O I/O I/O I/O I/O I/O I/O I/O I/O I/O I/O I/O I/O I/O I/O I/O I/O
X X X X X Z Z Z Z Z Z Z Z Z Z Z Z Z Z Z Z Z Z Z Z Z Z Z Z Z Z Z Z Z Z Z Z Z
LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA
Zarlink Semiconductor Inc.
Description
WC Switch (MHz)
Interface
Reset
Type
Pull
Pin
I/O
147
MT92210
Pin Description Table (continued)
SIGNAL Name Nom Switch (MHz)
Data Sheet
M30 V30 R26 W26 Y28 Y26 V27 W29 N27 K27 P26 N29 L30 M28 Y27 W30 V29 M29 N26 H28 L28 K26 M26 J29 W28 V26
memb_d[15] memb_p[0] memb_p[1] memb_cs[0] memb_cs[2] memb_cs[3] memb_rw memb_bws[1] memb_a[0] memb_a[1] memb_a[2] memb_a[3] memb_a[4] memb_a[5] memb_a[6] memb_a[8] memb_a[9] memb_a[10] memb_a[11] memb_a[12] memb_a[13] memb_a[14] memb_a[15] memb_a[16] memb_a[17] memb_a[18]
MEMB MEMB MEMB MEMB MEMB MEMB MEMB MEMB MEMB MEMB MEMB MEMB MEMB MEMB MEMB MEMB MEMB MEMB MEMB MEMB MEMB MEMB MEMB MEMB MEMB MEMB MEMB MEMB MEMB MEMC MEMC MEMC MEMC MEMC MEMC MEMC MEMC MEMC
9.375 9.375 9.375 18.75 18.75 18.75 18.75 18.75 18.75 18.75 18.75 18.75 18.75 18.75 18.75 18.75 18.75 18.75 18.75 18.75 18.75 18.75 18.75 18.75 18.75 18.75 18.75 18.75 18.75 9.375 9.375 9.375 9.375 9.375 9.375 9.375 9.375 9.375
37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5
I/O I/O I/O O O O O O O O O O O O O O O O O O O O O O O O O O O I/O I/O I/O I/O I/O I/O I/O I/O I/O
Z Z Z 1 1 1 1 1 1 1 X X X X X X X X X X X X X X X X X X X Z Z Z Z Z Z Z Z Z
LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA
AB27 memb_cs[1]
AA27 memb_bws[0]
AA26 memb_a[7]
AH24 memc_d[0] AK24 memc_d[1] AK22 memc_d[2] AH23 memc_d[3] AG24 memc_d[4] AJ21 AJ22 memc_d[5] memc_d[7] AK21 memc_d[6] AG23 memc_d[8]
148
Zarlink Semiconductor Inc.
Description
WC Switch (MHz)
Interface
Reset
Type
Pull
Pin
I/O
Data Sheet
Pin Description Table (continued)
SIGNAL Name Nom Switch (MHz)
MT92210
AJ20 AF19 AF21 AJ19 AF20
memc_d[9] memc_d[10] memc_d[11] memc_d[13] memc_d[14]
MEMC MEMC MEMC MEMC MEMC MEMC MEMC MEMC MEMC MEMC MEMC MEMC MEMC MEMC MEMC MEMC MEMC MEMC MEMC MEMC MEMC MEMC MEMC MEMC MEMC MEMC MEMC MEMC MEMC MEMC MEMC MEMC MEMC MEMC MEMC MEMC MEMC MEMC
9.375 9.375 9.375 9.375 9.375 9.375 9.375 9.375 9.375 9.375 9.375 9.375 9.375 9.375 9.375 9.375 9.375 9.375 9.375 9.375 9.375 9.375 9.375 9.375 9.375 9.375 9.375 18.75 18.75 18.75 18.75 18.75 18.75 18.75 18.75 18.75 18.75 18.75
37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5
I/O I/O I/O I/O I/O I/O I/O I/O I/O I/O I/O I/O I/O I/O I/O I/O I/O I/O I/O I/O I/O I/O I/O I/O I/O I/O I/O O O O O O O O O O O O
Z Z Z Z Z Z Z Z Z Z Z Z Z Z Z Z Z Z Z Z Z Z Z Z Z Z Z 1 1 1 1 1 1 1 1 1 1 1
LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA
AK20 memc_d[12]
AH20 memc_d[15] AD29 memc_d[16] AE26 memc_d[17] AC29 memc_d[18] AH29 memc_d[19] AD26 memc_d[20] AC30 memc_d[21] AH30 memc_d[22] AE30 memc_d[23] AB26 memc_d[24] AE27 memc_d[25] AE29 memc_d[26] AD30 memc_d[27] AG28 memc_d[28] AD28 memc_d[29] AC26 memc_d[30] AA29 memc_d[31] AF23 memc_p[0] AG22 memc_p[1] AK26 memc_p[2] AC28 memc_p[3] AG26 memc_cs[0] AK27 memc_cs[1] AB29 memc_cs[2] AA30 memc_cs[3] AF22 memc_rw AH28 memc_bws[0] AG25 memc_bws[1] AJ25 memc_bws[2] AK23 memc_bws[3] AG16 memc_cas[0] Y29 memc_cas[1]
Zarlink Semiconductor Inc.
Description
WC Switch (MHz)
Interface
Reset
Type
Pull
Pin
I/O
149
MT92210
Pin Description Table (continued)
SIGNAL Name Nom Switch (MHz)
Data Sheet
AB30 memc_ras AG19 memc_we[0] AC27 memc_we[1] AG21 memc_a[0] AJ17 AF18 memc_a[1] memc_a[3] AK18 memc_a[2] AH19 memc_a[4] AK16 memc_a[5] AK17 memc_a[6] AF17 AJ16 AF16 AJ18 AF27 AF24 memc_a[7] memc_a[9] memc_a[11] memc_a[13] memc_a[14] memc_a[15] AK15 memc_a[8] AG18 memc_a[10] AK19 memc_a[12]
MEMC MEMC MEMC MEMC MEMC MEMC MEMC MEMC MEMC MEMC MEMC MEMC MEMC MEMC MEMC MEMC MEMC MEMC MEMC MEMC MEMC UTOPIA B UTOPIA B
18.75 18.75 18.75 18.75 18.75 18.75 18.75 18.75 18.75 18.75 18.75 18.75 18.75 18.75 18.75 18.75 18.75 18.75 18.75 18.75 18.75 25 6.25
37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 37.5 25 12.5
O O O O O O O O O O O O O O O O O O O O O I/O 1. O 2. O
1 1 1 X X X X X X X X X X X X X X X X X X Z Z 1. U 2. D
LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 4 mA LVTTL 8 mA (F) LVTTL 4 mA (F) 1. MT92210 is a UTOPIA ATM Layer 2. MT92210 is a UTOPIA PHY Layer 1. MT92210 is a UTOPIA ATM Laye1. 2. MT92210 is a UTOPIA PHY Layer
AK25 memc_a[16] AG30 memc_a[17] E13 B13 txb_clk 1. txb_enb 2. txb_clav
E12
1. txb_clav 2. txb_enb
UTOPIA B
1. I 2. I
Z
1. D 2. U
LVTTL (F)
A13 D10 A11 E10 C11
txb_soc txb_prty txb_d[0] txb_d[1] txb_d[2]
UTOPIA B UTOPIA B UTOPIA B UTOPIA B UTOPIA B
6.25 6.25 6.25 6.25 6.25
12.5 12.5 12.5 12.5 12.5
O O O O O
Z Z Z Z Z
LVTTL 4 mA (F) LVTTL 4 mA (F) LVTTL 4 mA (F) LVTTL 4 mA (F) LVTTL 4 mA (F)
150
Zarlink Semiconductor Inc.
Description
WC Switch (MHz)
Interface
Reset
Type
Pull
Pin
I/O
Data Sheet
Pin Description Table (continued)
SIGNAL Name Nom Switch (MHz)
MT92210
C12 A12 B12 D13 D12 D11 E11
txb_d[3] txb_d[4] txb_d[5] txb_d[6] txb_d[7] rxb_clk 1. rxb_enb 2. rxb_clav
UTOPIA B UTOPIA B UTOPIA B UTOPIA B UTOPIA B UTOPIA B UTOPIA B
6.25 6.25 6.25 6.25 6.25 25 6.25
12.5 12.5 12.5 12.5 12.5 25 12.5
O O O O O I/O 1. O 2. O
Z Z Z Z Z Z Z 1. U 2. D
LVTTL 4 mA (F) LVTTL 4 mA (F) LVTTL 4 mA (F) LVTTL 4 mA (F) LVTTL 4 mA (F) LVTTL 8 mA (F) LVTTL 4 mA (F) 1. MT92210 is a UTOPIA ATM Layer 2. MT92210 is a UTOPIA PHY Layer 1. MT92210 is a UTOPIA ATM Layer 2. MT92210 is a UTOPIAPHY Layer
B9
1. rxb_cla 2. rxb_enb
UTOPIA B
1. I 2. I
Z
1. D 2. U
LVTTL (F)
D9 A10 A9 E7 E9 C8 D7 B10 A8 D8 D5 H2 F2 G2 E2
rxb_soc rxb_prty rxb_d[0] rxb_d[1] rxb_d[2] rxb_d[3] rxb_d[4] rxb_d[5] rxb_d[6] rxb_d[7] txa_clk txa_d[0] txa_d[1] txa_d[2] txa_d[3]
UTOPIA B UTOPIA B UTOPIA B UTOPIA B UTOPIA B UTOPIA B UTOPIA B UTOPIA B UTOPIA B UTOPIA B NETA NETA NETA NETA NETA 25 6.25 6.25 6.25 6.25 25 12.5 12.5 12.5 12.5
I I I I I I I I I I I/O O O O O
Z Z Z Z Z Z Z Z Z Z Z Z Z Z Z
LVTTL (F) LVTTL (F) LVTTL (F) LVTTL (F) LVTTL (F) LVTTL (F) LVTTL (F) LVTTL (F) LVTTL (F) LVTTL (F) LVTTL 8 mA (F) LVTTL 8 mA (F) LVTTL 8 mA (F) LVTTL 8 mA (F) LVTTL 8 mA (F)
Zarlink Semiconductor Inc.
Description
WC Switch (MHz)
Interface
Reset
Type
Pull
Pin
I/O
151
MT92210
Pin Description Table (continued)
SIGNAL Name Nom Switch (MHz)
Data Sheet
D3 A4 D4 A7 B3 E8 E6 C4 B8 B6 A3 B4 B7 B15
txa_d[4] txa_d[5] txa_d[6] txa_d[7] txa_d[8] txa_d[9] txa_d[10] txa_d[11] txa_d[12] txa_d[13] txa_d[14] txa_d[15] txa_prty 1. txa_enb 2. txa_clav 3. txa_enb
NETA NETA NETA NETA NETA NETA NETA NETA NETA NETA NETA NETA NETA NETA
6.25 6.25 6.25 6.25 6.25 6.25 6.25 6.25 6.25 6.25 6.25 6.25 6.25 6.25
12.5 12.5 12.5 12.5 12.5 12.5 12.5 12.5 12.5 12.5 12.5 12.5 12.5 12.5
O O O O O O O O O O O O O O
Z Z Z Z Z Z Z Z Z Z Z Z Z Z 1. U 2. D 3. U
LVTTL 8 mA (F) LVTTL 8 mA (F) LVTTL 8 mA (F) LVTTL 8 mA (F) LVTTL 8 mA (F) LVTTL 8 mA (F) LVTTL 8 mA (F) LVTTL 8 mA (F) LVTTL 8 mA (F) LVTTL 8 mA (F) LVTTL 8 mA (F) LVTTL 8 mA (F) LVTTL 8 mA (F) LVTTL 8 mA (F) 1. MT92210 is UTOPIA ATM Layer 2.MT92210 is UTOPIA PHY Layer 3. MT92210 is POS-PHY Link Layer 1. MT92210 is UTOPIA ATM/PHY Layer 2. MT92210 is a POS-PHY Link Layer 1. MT92210 is a UTOPIA ATM Layer 2. MT92210 is a UTOPIA PHY Layer 3. MT92210 is a POS-PHY Link Layer
A5
1. txa_soc 2. txa_sop
NETA
6.25
12.5
O
Z
LVTTL 8 mA (F)
C2
1. txa_clav 2. txa_enb 3. txa_ptpa
NETA
I
1. D 2. U 3. D
LVTTL (F)
D22 E20 B19 E18
txa_addr[0] txa_addr[1] txa_addr[2] 1. txa_addr[3] 2. txa_mod
NETA NETA NETA NETA 6.25 12.5
I I I 1. I 2. O Z
LVTTL LVTTL LVTTL LVTTL 8 mA MT92210 is UTOPIA PHY Layer 1. MT92210 is UTOPIA PHY Layer 2. MT92210 is POS-PHY Link Layer 1. MT92210 is UTOPIA PHY Layer 2. MT92210 is POS-PHY Link Layer
A21
1. txa_addr[4] 2. txa_eop
NETA
6.25
12.5
1. I 2. O
Z
LVTTL 8 mA
L1 K5 M5 L5
rxa_d[0] rxa_d[1] rxa_d[2] rxa_d[3]
NETA NETA NETA NETA
I I I I
LVTTL (F) LVTTL (F) LVTTL (F) LVTTL (F)
152
Zarlink Semiconductor Inc.
Description
WC Switch (MHz)
Interface
Reset
Type
Pull
Pin
I/O
Data Sheet
Pin Description Table (continued)
SIGNAL Name Nom Switch (MHz)
MT92210
J2 H4 L2 J1 H3 G4 K2 G1 G3 D1 H5 F1 J5 H1
rxa_d[4] rxa_d[5] rxa_d[6] rxa_d[7] rxa_d[8] rxa_d[9] rxa_d[10] rxa_d[11] rxa_d[12] rxa_d[13] rxa_d[14] rxa_d[15] rxa_prty 1. rxa_soc 2. rxa_sop
NETA NETA NETA NETA NETA NETA NETA NETA NETA NETA NETA NETA NETA NETA
I I I I I I I I I I I I I I
LVTTL (F) LVTTL (F) LVTTL (F) LVTTL (F) LVTTL (F) LVTTL (F) LVTTL (F) LVTTL (F) LVTTL (F) LVTTL (F) LVTTL (F) LVTTL (F) LVTTL (F) LVTTL (F) 1. MT92210 is UTOPIA ATM/PHY Layer 2. MT92210 is POS-PHY Link Layer 1. MT92210 is a UTOPIA ATM Layer 2. MT92210 is a UTOPIA PHY Layer 3. MT92210 is a POS-PHY Link Layer 1. MT92210 is a UTOPIA ATM Layer 2. MT92210 is a UTOPIA PHY Layer 3. MT92210 is a POS-PHY Link Layer
G5
1. rxa_enb 2. rxa_clav 3. rxa_enb
NETA
6.25
12.5
O
Z
LVTTL 8 mA (F)
C1
1. rxa_clav 2. rxa_enb 3. rxa_prpa
NETA
I
LVTTL (F)
E4 A20 D20
rxa_clk rxa_addr[0] 1. rxa_addr[1] 2. rxa_val
NETA NETA NETA
25
25
I/O I I
Z
LVTTL 8 mA (F) LVTTL LVTTL 1. MT92210 is UTOPIA PHY Layer 2. MT92210 is POS-PHY Link Layer 1. MT92210 is UTOPIA PHY Layer 2. MT92210 is POS-PHY Link Layer 1. MT92210 is UTOPIA PHY Layer 2. MT92210 is POS-PHY Link Layer
E21
1. rxa_addr[2] 2. rxa_err
NETA
I
LVTTL
E19
1. rxa_addr[3] 2. rxa_mod
NETA
I
LVTTL
Zarlink Semiconductor Inc.
Description
WC Switch (MHz)
Interface
Reset
Type
Pull
Pin
I/O
153
MT92210
Pin Description Table (continued)
SIGNAL Name Nom Switch (MHz)
Data Sheet
D23
1. rxa_addr[4] 2. rxa_eop
NETA
I
LVTTL
1. MT92210 is UTOPIA PHY Layer 2. MT92210 is POS-PHY Link Layer
B14 A18 B16 E16 C16 D16 D15 C15 E15 A16 A17 E17 B17 C19 E14 A2 A29 AA3 AB3 AE3 AF3 AF28 AG4
etha_tx_clk etha_tx_en etha_tx_d[0] etha_tx_d[1] etha_tx_d[2] etha_tx_d[3] etha_col etha_crs etha_rx_clk etha_rx_d[0] etha_rx_d[1] etha_rx_d[2] etha_rx_d[3] etha_rx_er etha_rx_dv vss_ring vss_ring vss_ring vss_ring vss_ring vss_ring vss_ring vss_ring
NETA NETA NETA NETA NETA NETA NETA NETA NETA NETA NETA NETA NETA NETA NETA Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power 6.25 6.25 6.25 6.25 6.25 12.5 12.5 12.5 12.5 12.5
I O O O O O I I I I I I I I I 0 X X X X
LVTTL (F) LVTTL 4 mA (F) LVTTL 4 mA (F) LVTTL 4 mA (F) LVTTL 4 mA (F) LVTTL 4 mA (F) LVTTL (F) LVTTL (F) LVTTL (F) LVTTL (F) LVTTL (F) LVTTL (F) LVTTL (F) LVTTL (F) LVTTL (F) 0V Power Supply used for core and I/Os.
AA28 vss_ring AB28 vss_ring AE28 vss_ring
AG27 vss_ring AH05 vss_ring AH06 vss_ring AH09 vss_ring AH10 vss_ring AH13 vss_ring AH14 vss_ring AH17 vss_ring
154
Zarlink Semiconductor Inc.
Description
WC Switch (MHz)
Interface
Reset
Type
Pull
Pin
I/O
Data Sheet
Pin Description Table (continued)
SIGNAL Name Nom Switch (MHz)
MT92210
AH18 vss_ring AH21 vss_ring AH22 vss_ring AH25 vss_ring AH26 vss_ring AJ1 AJ2 AJ29 AJ30 AK2 B1 B2 B29 B30 C3 C5 C6 C9 C10 C13 C14 C17 C18 C21 C22 C25 C26 D27 E3 E28 F3 F28 J3 J28 K3 K28 N3 vss_ring vss_ring vss_ring vss_ring vss_ring vss_ring vss_ring vss_ring vss_ring vss_ring vss_ring vss_ring vss_ring vss_ring vss_ring vss_ring vss_ring vss_ring vss_ring vss_ring vss_ring vss_ring vss_ring vss_ring vss_ring vss_ring vss_ring vss_ring vss_ring vss_ring vss_ring vss_ring
Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power
AK29 vss_ring
Zarlink Semiconductor Inc.
Description
WC Switch (MHz)
Interface
Reset
Type
Pull
Pin
I/O
155
MT92210
Pin Description Table (continued)
SIGNAL Name Nom Switch (MHz)
Data Sheet
N13 N14 N15 N16 N17 N18 N28 P3 P13 P14 P15 P16 P17 P18 P28 R13 R14 R15 R16 R17 R18 T13 T14 T15 T16 T17 T18 U3 U13 U14 U15 U16 U17 U18 U28 V3 V13 V14
vss_ring vss_ring vss_ring vss_ring vss_ring vss_ring vss_ring vss_ring vss_ring vss_ring vss_ring vss_ring vss_ring vss_ring vss_ring vss_ring vss_ring vss_ring vss_ring vss_ring vss_ring vss_ring vss_ring vss_ring vss_ring vss_ring vss_ring vss_ring vss_ring vss_ring vss_ring vss_ring vss_ring vss_ring vss_ring vss_ring vss_ring vss_ring
Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power
156
Zarlink Semiconductor Inc.
Description
WC Switch (MHz)
Interface
Reset
Type
Pull
Pin
I/O
Data Sheet
Pin Description Table (continued)
SIGNAL Name Nom Switch (MHz)
MT92210
V15 V16 V17 V18 V28
vss_ring vss_ring vss_ring vss_ring vss_ring
Power Power Power Power Power Power 3.3V Power Supply used for core and I/Os.
AA25 vdd33_ring
AB6 AC6 AE8 AE9
vdd33_ring vdd33_ring vdd33_ring vdd33_ring
Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power
AD25 vdd33_ring
AE12 vdd33_ring AE13 vdd33_ring AE16 vdd33_ring AE17 vdd33_ring AE20 vdd33_ring AE21 vdd33_ring AE24 vdd33_ring AE25 vdd33_ring F6 F7 F10 F11 F14 F15 F18 F19 F22 F23 G6 H25 J25 K6 L6 M25 N25 P6 vdd33_ring vdd33_ring vdd33_ring vdd33_ring vdd33_ring vdd33_ring vdd33_ring vdd33_ring vdd33_ring vdd33_ring vdd33_ring vdd33_ring vdd33_ring vdd33_ring vdd33_ring vdd33_ring vdd33_ring vdd33_ring
Zarlink Semiconductor Inc.
Description
WC Switch (MHz)
Interface
Reset
Type
Pull
Pin
I/O
157
MT92210
Pin Description Table (continued)
SIGNAL Name Nom Switch (MHz)
Data Sheet
R6 T25 U25 V6 W6 Y25 AA6 AD6 AE6 H06 J6 M6 N6 T6 U6 Y6
vdd33_ring vdd33_ring vdd33_ring vdd33_ring vdd33_ring vdd33_ring vdd33_ring vdd33_ring vdd33_ring vdd33_ring vdd33_ring vdd33_ring vdd33_ring vdd33_ring vdd33_ring vdd33_ring
Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power
AE07 vdd33_ring AE10 vdd33_ring AE11 vdd33_ring AE14 vdd33_ring AE15 vdd33_ring AE18 vdd33_ring AE19 vdd33_ring AE22 vdd33_ring AE23 vdd33_ring AB25 vdd33_ring AC25 vdd33_ring F25 G25 K25 L25 P25 R25 V25 W25 F8 F9 F12 vdd33_ring vdd33_ring vdd33_ring vdd33_ring vdd33_ring vdd33_ring vdd33_ring vdd33_ring vdd33_ring vdd33_ring vdd33_ring
158
Zarlink Semiconductor Inc.
Description
WC Switch (MHz)
Interface
Reset
Type
Pull
Pin
I/O
Data Sheet
Pin Description Table (continued)
SIGNAL Name Nom Switch (MHz)
MT92210
F13 F16 F17 F20 F21 F24
vdd33_ring vdd33_ring vdd33_ring vdd33_ring vdd33_ring vdd33_ring
Power Power Power Power Power Power Power Power Power Additional 0V power supply pins. Additional 0V power supply pins. 5V Power Supply used for 5V tolerance. May be connected to 3.3Vpower supply if all devices connected to the MT92210 are 3.3V only. See vdd5_0. See vdd5_0. See vdd5_0. See vdd5_0. See vdd5_0. See vdd5_0. See vdd5_0. See vdd5_0. See vdd5_0. See vdd5_0. 0V PLL power supply. See Figure PLL noise reduction circuit for reference design. 2.5V PLL power supply. See Figure PLL noise reduction circuit for reference design. 2.5V PLL power supply. See Figure PLL noise reduction circuit for reference design. 0V PLL power supply. See Figure PLL noise reduction circuit for reference design.
AK14 Vss_0 AJ15 A6 vss_1 vdd5_0
B11 D17 F4 M4 Y1 AC5 AG6 AG9 AH11 AJ3
vdd5_1 vdd5_2 vdd5_3 vdd5_4 vdd5_5 vdd5_6 vdd5_7 vdd5_8 vdd5_9 fc1pll_pllvss
Power Power Power Power Power Power Power Power Power Power Power
AH15 vdd5_10
AK3
fc1pll_pllvdd
Power
AJ26
fc2pll_pllvdd
Power
AF25
fc2pll_pllvss
Power
Zarlink Semiconductor Inc.
Description
WC Switch (MHz)
Interface
Reset
Type
Pull
Pin
I/O
159
MT92210
Pin Description Table (continued)
SIGNAL Name Nom Switch (MHz)
Data Sheet
C29
h110pll_pllvss
Power
0V PLL power supply. See Figure PLL noise reduction circuit for reference design. 2.5V PLL power supply. See Figure PLL noise reduction circuit for reference design. 2.5V Core power supply. See vdd25_0 See vdd25_0 See vdd25_0 See vdd25_0 See vdd25_0 See vdd25_0 See vdd25_0 See vdd25_0 See vdd25_0 See vdd25_0 See vdd25_0 See vdd25_0 See vdd25_0 See vdd25_0 See vdd25_0 See vdd25_0 See vdd25_0 See vdd25_0 See vdd25_0 See vdd25_0 See vdd25_0 See vdd25_0 See vdd25_0 Leave these "No Connect" pins floating.
D29
h110pll_pllvdd
Power
A15 B5 B22 C7 D14 D21 F5 H26 J27 L4 P4 P27 U4 U27 Y3 AD3
vdd25_0 vdd25_1 vdd25_2 vdd25_3 vdd25_4 vdd25_5 vdd25_6 vdd25_7 vdd25_8 vdd25_9 vdd25_10 vdd25_11 vdd25_12 vdd25_13 vdd25_14 vdd25_15
Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power
AD27 vdd25_16 AG11 vdd25_17 AG15 vdd25_18 AG17 vdd25_19 AG20 vdd25_20 AG29 vdd25_21 AH3 A27 B27 D2 D6 E1 E5 E25 vdd25_22 NC NC NC NC NC NC NC AH27 vdd25_23
160
Zarlink Semiconductor Inc.
Description
WC Switch (MHz)
Interface
Reset
Type
Pull
Pin
I/O
Data Sheet
Pin Description Table (continued)
SIGNAL Name Nom Switch (MHz)
MT92210
L27 R5 AF6 AF26 AF29 AF30 AG8
NC NC NC NC NC NC NC
AG12 NC AG14 NC AH4 AH7 AJ4 AJ27 AJ28 NC NC NC NC NC
AH12 NC
AK28 NC
vdd25 10 ohm fc1pll_pllvdd 1/10W 5% 0.1uF 50V 10% fc1pll_pllvss
vdd25
10 ohm fc2pll_pllvdd 1/10W 5% 0.1uF 50V 10% fc2pll_pllvss
vdd25
10 ohm h110pll_pllvdd 1/10W 5% 0.1uF 50V 10% h110pll_pllvss
Figure 84 - PLL Noise Reduction Circuits
Zarlink Semiconductor Inc.
Description
WC Switch (MHz)
Interface
Reset
Type
Pull
Pin
I/O
161
MT92210
Data Sheet
162
Zarlink Semiconductor Inc.
Data Sheet
13.0
13.1
MT92210
Electrical Characteristics
Absolute Maximum Conditions
Absolute Maximum Conditions Parameter
DC Supply Voltage2 3.3 V DC Supply Voltage LVTTL Input Voltage 3.3 V Drive Input Voltage 5 V Compatible Input Voltage DC Input Current Storage Temperature Range (Ceramic) Storage Temperature Range (Plastic)
Symbol
VDD VDD3.3 VIN2.5 VIN3.3 VIN5 IIN TSTG TSTG -0.3 to + 3.1 -0.3 to + 3.9
Limits
V V V V V uA C C V
Unit
-1.0 to VDD + 0.3 -1.0 to VDD3.3 + 0.0 -1.0 to 6.5 +10 -65 to + 150 -40 to + 125 VDD Overstress: 2x VDD (7.2 V)
ESD Per MIL-STD-883 Test Method 3015, Notice 8, Spec 2001V Latchup Over/undershoot: + 150 mA, 125 C
Note 1: Note 2: Note 3:
Operation beyond the limits specified in this table may cause permanent device damage. Internal cells (core) and standard I/Os operate at 2.5 V. Voltage are referenced to ground (VSS) unless otherwise stated
13.2
Recommended Operating Conditions
Recommended Operating Conditions Parameter
DC Supply Voltage
2
Symbol
VDD TJ TJ
Limits1
+ 2.25 to 2.75 -40 to + 125 0 to + 85 V C C
Unit
Operating Junction Temperature Range Industrial Commercial
Note 1:
Note 2: Note 3:
For normal device operation, adhere to the limits in this table. Sustained operation of a device at conditions exceeding these values, even if they are within the absolute maximum rating limits, may result in permanent device damage or impaired device reliability. Device functionality to stated DC and AC limits is not guaranteed if conditions exceed recommended operating conditions. Core supply voltage (2.5 V nominal). Voltage are reference to ground (Vss) unless otherwise stated
13.3
DC Characteristics
Standard 2.5V LVTLL Buffers Parameter
Supply Voltage Power Dissipation Input Low Voltage
Symbol
VDD PD VIL _
Condition
Min
2.25
Typ
2.5
Max
2.75 2.33
Unit
V W V
1023 RTP Connections, all output pins loaded _ Vss-0.5 _
0.7
Zarlink Semiconductor Inc.
163
MT92210
Standard 2.5V LVTLL Buffers (continued) Parameter
Input High Voltage Switching Threshold Schmitt Trigger, Positive going Threshold Schmitt Trigger, Negative going Threshold Schmitt Trigger, Hysteresis Input Current Inputs with Pull-down Resistors Inputs with Pull-up Resistors
Note 1: Note 2:
Data Sheet
Symbol
VIH VT VT+ VT-
Condition
LVTTL Comm/Ind Temp Range - - - -
Min
1.7 - - 0.8 0.6 -10 80
Typ
- 1.35 1.7 1.0 0.7 11 200
Max
VDD +0.3 2.0 2.0 - - 10 390
Unit
V V V V V uA uA
IIN
VIN = VDD or VSS VIN = VDD
-28 -185 -393 uA VIN = VSS Industrial junction temperature range: - 40 to + 125 C, + 5% power supply, commercial junction temperature range: 0 to 85 C, + 5% power supply. Output using single buffer structure (excluding package).
Standard 3.3V LVTLL Buffers and 5V Compatible Buffers Parameter
Supply Voltage Input Low Voltage Input High Voltage
Symbol
VDD3.3 VIL VIH _ _
Condition1
Min
3.0 VDD3.30.5 2.0 2.0 - - 3.3 _ _ _ 1.4 1.7
Typ
3.6 0.8
Max
Unit
V V V V V V
LVTTL Comm/Ind Temp Range 5-Volt Compatible - -
VDD3.3 + 0.3 5.5 2.0 2.0
Switching Threshold Schmitt Trigger, Positive going Threshold Schmitt Trigger, Negative going Threshold Schmitt Trigger, Hysteresis Input Current Inputs with Pull-down Resistors Inputs with Pull-up Resistors Output High Voltage Output Low Voltage
VT VT+
VT-
-
0.8
1.0
-
V
- IIN VIN = VDD or VSS VIN = VDD VIN = VSS VOH VOL _ _
0.6 -10 35 -35 2.4 _
0.7 11 115 -115 _ 0.2
- 10 222 -214 VDD3.3 0.4
V uA uA uA V V
164
Zarlink Semiconductor Inc.
Data Sheet
Standard 3.3V LVTLL Buffers and 5V Compatible Buffers (continued) Parameter
3-state Output Leakage Current Input Capacitance2
MT92210
Symbol
IOZ CIN
Condition1
VOH=VSS or VDD3.3 Input and Bidirectional Buffers 5-volt Compatible Output Buffer 5-volt Compatible
Min
-10 4.0 4.6 4.0 4.6 11
Typ
10
Max
Unit
uA pF pF pF pF
Output Capacitance
Note 1: Note 2:
COUT
Industrial junction temperature range: - 40 to + 125 C, + 5% power supply, commercial junction temperature range: 0 to 85 C, + 5% power supply. Output using single buffer structure (excluding package).
13.4
Clock Signals
Clock Signals
Clock Networks Maximum Duty Cycle Maximum Frequency Minimum Duty Cycle Minimum Frequency Required For Device Operation Typical Frequency
mem_clk_sar_i mem_clk_net_i upclk rxa_clk rxb_clk txa_clk txb_clk etha_tx_clk etha_rx_clk pll_clk ct_c8_a/b
10 MHz 10 MHz 1 MHz 1 MHz 1 MHz 1 MHz 1 MHz 2.5 MHz 2.5 MHz 8.192 MHz 8.192 MHz
60 MHz 80 MHz 40 MHz 25 MHz 25 MHz 25 MHz 25 MHz 25 MHz 25 MHz
100 MHz 100 MHz 66 MHz 50 MHz 50 MHz 50 MHz 50 MHz 25 MHz 25 MHz 65.536 MHz 8.192 MHz
Yes Yes Yes No No No No No No No No
40% 40% 40% 40% 40% 40% 40% 40% 40% 40% 40%
60% 60% 60% 60% 60% 60% 60% 60% 60% 60% 60%
0 ps 400 ps 400 ps 400 ps 400 ps 400 ps 400 ps 400 ps 400 ps 400 ps 50 ns
Zarlink Semiconductor Inc.
Accepted Jitter (cycle-to-cycle)
165
Clock Name
MT92210
13.5 13.5.1 AC Characteristics Intel/Motorola CPU Interface
Write Access t1 write_access_active* inmo_a[14:0] / inmo_a_das inmo_d[15:0] inmo_rdy_ndtack t4 t5 Read Access t1 read_access_active* inmo_a[14:0] / inmo_a_das inmo_d[15:0] inmo_rdy_ndtack t8 t4 t7 t13 t6 t2 t6 t2 t2
Data Sheet
t2
*Access Active Generation inmo_cs inmo_wr_rw write_access_active inmo_cs inmo_rd_ds read_access_active
Notes: 1. inmo_cs and inmo_wr_rw must not have coinciding edges in opposite directions to prevent glitches on the write_access_active signal. 2. inmo_cs and inmo_rd_ds must not have coinciding edges in opposite directions to prevent glitches on the read_access_active signal.
Figure 85 - Non-multiplexed CPU Interface - Intel Mode
166
Zarlink Semiconductor Inc.
Data Sheet
Write Access t1 write_access_active* inmo_a[14:0] / inmo_a_das inmo_d[15:0] inmo_rdy_ndtack t9 t5 Read Access t1 read_access_active* inmo_a[14:0] / inmo_a_das inmo_d[15:0] inmo_rdy_ndtack t9 t8 t7 *Access Active Generation inmo_cs read_access_active inmo_rd_ds inmo_wr_rw t14 t12 t10 t11 t3 t3 t10 t11 t3 t3
MT92210
inmo_cs inmo_rd_ds inmo_wr_rw
write_access_active
Notes: 1. inmo_cs, inmo_cs must not have coinciding edges in opposite directions to prevent glitches on the write_access_active/read_access_active signals. 2. rd_rw_n must be stable any time both inmo_cs and inmo_rd_ds are low to prevent glitches on the write_access_active/read_access_active signals.
Figure 86 - Non-multiplexed CPU Interface - Motorola Mode
Zarlink Semiconductor Inc.
167
MT92210
t15 t1 t16 t17 write_access_active* inmo_ale inmo_d[15:0] inmo_rdy_ndtack t1 t6 t4 t15 t1 t16 t17 read_access_active* inmo_ale inmo_d[15:0] inmo_rdy_ndtack t8 t4 t7 t13 t6 t5 Read Access t2 t2 Write Access t2 t2
Data Sheet
*Access Active Generation inmo_cs inmo_wr_rw write_access_active inmo_cs inmo_rd_ds read_access_active
Notes: 1. inmo_cs and inmo_wr_rw must not have coinciding edges in opposite directions to prevent glitches on the write_access_active signal. 2. inmo_cs and inmo_rd_ds must not have coinciding edges in opposite directions to prevent glitches on the read_access_active signal.
Figure 87 - Multiplexed CPU Interface - Intel Mode
168
Zarlink Semiconductor Inc.
Data Sheet
t15 t1 write_access_active* inmo_ale inmo_d[15:0] inmo_rdy_ndtack t9 t1 t5 Read Access t1 t16 t17 t3 t3 t10 t11 t16 t17 Write Access t3 t3
MT92210
t15
read_access_active* inmo_ale inmo_d[15:0] inmo_rdy_ndtack t9
t8 t7
t14
t12 t10 t11
*Access Active Generation inmo_cs inmo_rd_ds inmo_wr_rw read_access_active inmo_cs inmo_rd_ds inmo_wr_rw write_access_active
Notes: 1. inmo_cs, inmo_cs must not have coinciding edges in opposite directions to prevent glitches on the write_access_active/read_access_active signals. 2. rd_rw_n must be stable any time both inmo_cs and inmo_rd_ds are low to prevent glitches on the write_access_active/read_access_active signals.
Figure 88 - Multiplexed CPU Interface - Motorola Mode
AC Characteristics - CPU Interface Symbol
t1
Description
write_access_active falling edge / read_access_active falling edge to inmo_a valid (non-multiplexed) inmo_a_das valid (non-multiplexed) inmo_d valid (writes) inmo_ale fall (multiplexed)
Min
Typical
Max
2 * upclkp - 4
Unit
ns
Notes
Zarlink Semiconductor Inc.
169
MT92210
AC Characteristics - CPU Interface (continued) Symbol
t2
Data Sheet
Description
inmo_rdy_ndtack rising edge to write_access_active rising edge (writes) read_access_active rising edge (reads) inmo_ale rising edge (multiplexed) inmo_d invalid (writes) inmo_a invalid (non-multiplexed) inmo_a_das invalid (non-multiplexed) inmo_rdy_ndtack falling edge to write_access_active rising edge (writes) read_access_active rising edge (reads) inmo_ale rising edge (multiplexed) inmo_d invalid (writes) inmo_a invalid (non-multiplexed) inmo_a_das invalid (non-multiplexed) write_access_active falling edge / read_access_active falling edge to inmo_rdy_ndtack falling edge Write Access Time (all writes) write_access_active rising edge / read_access_active rising edge to inmo_rdy_ndtack tri-state Read Access Time (to cpureg) Read Access Time (to internal reg/mem) Read Access Time (to external memory) read_access_active falling edge to inmo_d driven 0 0
Min
Typical
Max
Unit
ns
Notes
t3
0
ns
t4
0
8
ns
t5 t6
6 * upclkp
see Table 51 15
ns ns
t7 t7 t7 t8
6 * upclkp see Table 52 see Table 52 3 * upclkp - 4 see Table 52 see Table 52
ns ns ns ns
170
Zarlink Semiconductor Inc.
Data Sheet
AC Characteristics - CPU Interface (continued) Symbol
t9
MT92210
Description
read_access_active falling edge / write_access_active falling edge to inmo_rdy_ndtack driven high write_access_active rising edge / read_access_active rising edge to inmo_rdy_ndtack rising edge inmo_rdy_ndtack rising edge to inmo_rdy_ndtack tri-state read_access_active rising edge to inmo_d tri-state inmo_d valid to inmo_rdy_ndtack rising edge inmo_d valid to inmo_rdy_ndtack falling edge inmo_ale high pulse width inmo_d / inmo_a /inmo_a_das valid to inmo_ale falling edge inmo_ale falling edge to inmo_d / inmo_a / inmo_a_das invalid 0
Min
Typical
8
Max
Unit
Notes
t10
0
9
t11
1.5
6
t12
0
10
ns
t13 t14 t15 t16
upclkp - 4 upclkp - 4 5 5
ns ns ns ns
t17
5
ns
Symbol
t5 t5 t5
Description
Register and Internal Memory SSRAM SDRAM 640 680 720 760 760 820
Max.
ns ns ns ns ns ns
Unit
Test Conditions
Note 1 Note 2 Note 1 Note 2 Note 1 Note 2
Table 51 - t5 Write Access Time
Note 1: Note 2: Note 1: MCLK_SAR = MCLK_NET = 100 MHz, and Upclk = 32.768 MHz Note 2: MCLK_SAR = MCLK_NET = 82 MHz, and Upclk = 32.768 MHz
Zarlink Semiconductor Inc.
171
MT92210
Symbol
t7
Data Sheet
Description
Register 1 2 64 128
Burst Length
640 680 680 700 800 860 800 860 640 680 2 64 128 700 740
Max.
Unit
ns ns ns ns ns ns ns ns ns ns ns ns us us us us ns ns ns ns ns ns ns us ns ns ns ns ns us ns us
Test Conditions
Note 1 Note 2 Note 1 Note 2 Note 1 Note 2 Note 1 Note 2 Note 1 Note 2 Note 1 Note 2 Note 1 Note 2 Note 1 Note 2 Note 1 Note 2 Note 1 Note 2 Note 1 Note 2 Note 1 Note 2 Note 1 Note 2 Note 1 Note 2 Note 1 Note 2 Note 1 Note 2
t7
Internal Memory
1
1.26 1.4 1.26 1.4 720 760 740 860 860 980 860 1.1 720 760 740 760 860 1.26 860 1.4
t7
MEMC_SSRAM
1 2 64 128
t7
MEMA_SSRAM
1 2 64 128
Table 52 - t7 Read Access Time
172
Zarlink Semiconductor Inc.
Data Sheet
Symbol
t7
MT92210
Description
MEMB_SSRAM 1 2 64 128
Burst Length
700 760 740 920 860 960 860 960 760 820 2 64 128 800 840 940
Max.
Unit
ns ns ns ns ns ns ns ns ns ns ns ns ns us ns us
Test Conditions
Note 1 Note 2 Note 1 Note 2 Note 1 Note 2 Note 1 Note 2 Note 1 Note 2 Note 1 Note 2 Note 1 Note 2 Note 1 Note 2
t7
MEMC_SDRAM
1
1.04 940 1.2
Table 52 - t7 Read Access Time (continued)
Note 1: Note 2: Note 3: MCLK_SAR = MCLK_NET = 100 MHz, and Upclk = 32.768 MHz MCLK_SAR = MCLK_NET = 82 MHz, and Upclk = 32.768 MHz in burst read, all consecutive read access time after the first read is 400 ns/per read.
13.5.2
UTOPIA / POS-PHY / Ethernet Interface
t1 t2
etha_{tx,rx}_clk {tx,rx}{a,b}_clk input output t5 t3 X
X t4 t6
Figure 89 - UTOPIA / POS-PHY / Ethernet Timing
Zarlink Semiconductor Inc.
173
MT92210
Characteristics
t1 t2 t3 t4 t5 t6 Input setup time Input hold time Clock to data valid Clock to data change Clock rising to signal driven Clock rising to signal tri-state
Data Sheet
Symbol
t1 t2 t3 t4 t5 t6 2 2 1 10
Min
4 0
Typ
Max
Units
ns ns
Test Conditions
14
ns ns ns ns
Table 53 - Fields and Description
13.5.3
H.110 Interface
H.110 Input Sampling t3 t4 t5 t6
ct_c8 cd_d (1/2 cycle) cd_d (3/4 cycle) cd_d (4/4 cycle) t1 t2 H.110 Output t10 t11 ct_c8 cd_d (end of Time-Slot; early tri-state) cd_d (middle of Time-Slot) cd_d (beginning of Time-Slot) t13 t14 H.110 Frame Sampling t20 t21 ct_c8 ct_frame X t12
Figure 90 - H.110 Input Output
174
Zarlink Semiconductor Inc.
Data Sheet
H.110 Message Channel Clock t30 ct_c8 ct_frame mc_clock t31
MT92210
H.110 Message Transmission Delay t40 t41
mc_tx ct_mc
H.110 Message Reception Delay t50 ct_mc mc_rx
Figure 91 - H.110 Message Handling
Zarlink Semiconductor Inc.
175
MT92210
t60 ct_c8_a ct_c8_b ct_frame_a ct_frame_b c2 c4 sclk sclkx2 frcomp c16+ c16-
Data Sheet
Figure 14.1 - H.110 Clock Skew (when chip is Master) Symbol
t1 t2 t3 t4 t5 t6 t10 t11 t12 t13 t14 t20 t21 t30 t31 t40
Description
ct_c8 rise to ct_d valid ct_c8 rise to ct_d invalid ct_d valid to ct_c8 fall ct_c8 fall to ct_d invalid ct_d valid to ct_c8 rise ct_c8 rise to ct_d invalid ct_c8 rise to ct_d tri-state ct_c8 rise to ct_d invalid ct_c8 rise to ct_d invalid ct_c8 rise to ct_d driven ct_c8 rise to ct_d valid ct_frame valid to ct_c8 rise ct_c8 rise to ct_frame invalid ct_c8 rise to mc_clock rise ct_c8 fall to mc_clock fall mc_tx fall to ct_mc low 3 5 5
Min
Typical
69
Max
Unit
ns ns ns ns ns ns
Notes
102 5 5 5 0 122 102 2 2 22
ns ns ns ns ns ns ns
200 pf 200 pf 200 pf 200 pf 200 pf
15 15 15
ns ns ns 200 pf
Table 54 - Fields and Description
176 Zarlink Semiconductor Inc.
Data Sheet
Symbol
t41 t50 t60
MT92210
Description Min
3 3
Typical
15 15 5
Max
Unit
ns ns ns
Notes
200 pf 200 pf
mc_tx rise to ct_mc tri-state ct_mc fall to mc_rx fall ct_c8_a, ct_c8_b, ct_frame_a, ct_frame_b, c2, c4, sclk, sclkx2, frcomp, c16+, c16- maximum skew when generated by the chip
Table 54 - Fields and Description (continued)
13.5.4
External Memory Interface
t1 mem_clk_i mem_* (input) mem_* (output) t5 t3
t2
X
t4
X
t6
Figure 92 - External Memory Timing (both SSRAM and SDRAM)
Symbol
t1 t2 t3 t4 t5 t6
Description
Input setup time Input hold time Clock to data valid Clock to data change Clock rising to signal driven Clock rising to signal tri-state 1.1 1.9 3.1 0
Min
Typical
Max
ns ns 8.1 ns ns ns 4 ns
Unit
Notes
Load = 50 pf Load = 50 pf
Table 55 - Fields and Description
Zarlink Semiconductor Inc.
177
MT92210
Data Sheet
178
Zarlink Semiconductor Inc.
Data Sheet
Appendix A
Notes
MT92210
1. The RX Ethernet / RX POS module (eptoatm) does not pad any packets to the end of a cell. Thus a single dword of random data may reside in parts of a packet that would otherwise have contained zero padding. This abnormality has no adverse side-effects. 2. All four memory-controllers cannot limit the throughput of watomic accesses to their respective memories. Thus, the software may be able to "sink" the external memory bandwidth and make the chip fail. To avoid this, any burst of more than 16 consecutive watomic accesses should be isolated from other watomic accesses via 3 other (non-watomic) accesses. These can be three writes to registers (on the proper clock domain). So to break up watomic accesses to memory bank A/B, writes to the mainreg can be performed; to break up watomic accesses to memory bank C, writes to the netreg can be performed. 3. The number of bearers that is programmable in the disassembly structure has a maximum value of 255 rather than 256. 4. When the external SDRAM is configured to be 16 Megabytes rather than 32 Megabytes, the auto-clear function will initialize the links to values in the range 16-32 Megabytes. 5. The SDRAM refresh process will be active during the init of the chip. Therefore, to ensure that the SDRAM init sequence is executed without any refresh instructions being inserted, the sdram_refresh_cnt must be changed from a small value (e.g. 0x100) to 0xFFFF. This will create 65000 mclk_net cycles during which no refresh instructions will be executed. Once the init sequence is complete, the sdram_refresh_cnt must be returned to its valid value. A precise timer must be used to ensure that the sequence was executed within the time budget. 6. The packet disassembly module's extended PDV monitoring section analyzes the delay of packets in the negative direction instead of the positive direction, which means that a "late" packet will obtain a very small delta, while an "early" packet will obtain a very large delta. Because of this, the exponential section of the delay entries is located in the delay section in which early packet will arrive. In addition, the time_zero_delta field must be programmed to the total number of frames of latency with which the latest packet can be expected to arrive (from source to destination).
Zarlink Semiconductor Inc.
179
MT92210
Data Sheet
180
Zarlink Semiconductor Inc.
Data Sheet
Appendix B
HDLC Format, Including Zero-Insertion and Extraction
MT92210
The MT92210 supports 2 types of HDLC over the TDM bus: the first, bit-wise form of HDLC uses a control flag of "01111110" and inserts a '0' after every 5 '1's of payload. When using this form of HDLC, each HDLC packet must begin with a flag and end with a flag, although a single flag may represent both the end of a packet and the beginning of another. If neither flags nor data are being transmitted onto the bus, the idle code must be used: it is simply an endless string of '1's. Note that the idle code must be at least 7 bits long (7 '1's) to be valid The second form is a byte-wise HDLC format, which also uses "01111110" (7Eh) as a control flag. An actual 7Eh within the payload is replaced by 7Dh - 5Eh, while a 7Dh is replaced by 7Dh - 5Dh. On the SONET interface, a 7Dh - 7Eh control code indicate the abortion of the packet. This form of HDLC is easier in terms of computation (because it looks at each byte individually instead of each bit) and thus is easier for neighboring DSP to use. It does not contain an idle code: instead, the flag character is repeated endlessly until valid data is ready to be transmitted onto the bus. In both cases, the MT92210 can accept or generate an HDLC header that can contain 0, 1 or 2 address bytes, as well as a possible control byte. There is also an optional 16-bit CRC that may be added at the end of the packet. When using HDLC streams, the low 9 bits of the address are used to select the channel number. Finally, the payload of the mini-packet may range from 1 to 1500 bytes. Note that the payload of the mini-packet may include an RTP header. In RTP HDLC format, a complete RTP packet including RTP header is encapsulated.
FLAG
H0
H1
Cntrl
D0
D1
D2
D3
D4
CRC0
CRC1
FLAG
Figure 93 - Supported RTP HDLC Packet Format (after zero extraction)
1. 2. 3. 4. Address bytes can be 0, 1 or 2 byte(s). Control byte is optional. CRC bytes are optional Complete RTP packet starts from D0
Zarlink Semiconductor Inc.
181
MT92210
Data Sheet
182
Zarlink Semiconductor Inc.
Data Sheet
Appendix C
Standards & Specifications
MT92210
The MT92210 is designed to conform to sections of the following standards and specifications. Some of these specifications define requirements that can only be implemented in software. Some of the specifications are "umbrella" specifications to which the MT92210 only complies to portions of.
ECTF
H.100 Revision 1.0 Hardware Compatibility Specification: CT Bus H.110 Revision 1.0 Hardware Compatibility Specification: CT Bus
IEEE
802.3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications
IETF
RFC768 (also STD6): User Datagram Protocol RFC791 (also STD5): Internet Protocol Version 4 RFC826 (also STD37): Ethernet Address Resolution Protocol RFC894 (also STD41): Standard for the transmission of IP datagrams over Ethernet networks RFC1122 (also STD3): Requirements for Internet Hosts RFC1123 (also STD3): Requirements for Internet Hosts RFC1661 (also STD51): The Point-to-Point Protocol RFC1662 (also STD51): The Point-to-Point Protocol RFC1889: Real-Time Protocol RFC1890: Real-Time Protocol RFC2225: Classical IP and ARP over ATM RFC2460: Internet Protocol Version 6 RFC2464: Transmission of IPv6 Packets over Ethernet Networks RFC2684: Multi-protocol Encapsulation over ATM AAL5 Draft (draft-ietf-mpls-label-encaps-07): MPLS Label Stack Encoding
ITU
I.363.5: ATM Adaptation Layer 5 ATM Forum Af-lane-0021.000: LAN Emulation over ATM version 1.0 Af-lane-0084.000: LAN Emulation over ATM version 2 Af-lane-0112.000: LAN Emulation over ATM version 2 Af-mpoa-0114.000: Multi-protocol over ATM version 1.1
Zarlink Semiconductor Inc.
183
MT92210
Af-phy-0017.000: UTOPIA Specification Level 1, version 2.01 Af-phy-0039.000: UTOPIA Level 2, version 1.0 PMC-Sierra POS-PHY: Saturn Compatible Packet over SONET Interface Specification (Level 2)
Data Sheet
184
Zarlink Semiconductor Inc.
Data Sheet
Appendix D
Glossary of Terms Standard Terms and Abbreviations
MT92210
AAL0 (ATM Adaptation Layer 0): AAL0 is a straight packaging of 48 bytes of data within an ATM cell. AAL0 is often used to carry signaling ATM cells, which are treated in this device as "raw cells". AAL5 (ATM Adaptation Layer 5): AAL5 is a protocol used to carry higher-layer datagrams while enhancing the link layer with services available through ATM. Defined in the ITU standard I.363.5, AAL5 is typically used to carry IP datagrams over ATM, but can be used for other higher-layer protocols. ADPCM (Adaptive Differential Pulse Code Modulation): ADPCM is a compression standard that allows the encoding of PCM data at rates of 40, 32, 24 and 16 kbps. Defined by the ITU standard G.726. ADPCM running at 32 kbps is often used as the definition of "toll" quality, or quality that is comparable or superior to that of the PSTN today. Application data: The "data" unit carried by the transport layer. This will typically be the UDP payload in a voice-over-IP implementation, though it could be TCP payload or others for other applications. ARP (Address Resolution Protocol): A protocol designed for Ethernet that allows the MAC address associated to a network address (usually an IP address) to be known so the packet can be sent over Ethernet. Defined by IETF RFC826 & STD37. CLIP (CLassical IP Over ATM): Encapsulation of IP packets over AAL5 using LLC and SNAP header to identify the network protocol (in this case IP) being used. CPU (Central Processing Unit) CRC (Cyclic Redundancy Check): The CRC is a method of error detection and correction that is applied to a certain field of data. CRC is an efficient method of error detection because the odds of erroneously detecting a correct payload are low. Datagram: A logical entity containing an IP header and the IP message contained within. IP protocols communicate through datagrams, but these are sometimes fragmented on links. Datagrams are sent as packets on the link layer, and a datagram may be sent as one or many packets. FIFO (First In, First Out): A FIFO memory is one in which the first byte to have been written into the memory is the first one to be read from the read port. Frame: A unit of data transported on a link layer. In Ethernet, for example, a frame would contain the MAC header, the IP (or other) packet within, and the Ethernet trailer. H.110: A TDM bus standard developed by ECTF to provide backward compatibility to existing TDM busses with more bandwidth and potential for development. H.100 has a total bandwidth of 256 Mbps. On a compact PCI platform, the name H.110 is used for this bus, which keeps the same logical characteristics but different electrical ones. HDLC (High-level Data Link Control): An encapsulation protocol that defines specific bit patterns as delimiters and thus allows transmission of data over a serial link. In the MT92210, HDLC is used to carry variable-length packets on the H.110 bus. IP (Internet Protocol): Designed for use in interconnected systems of packet-switched computer communication networks, IP is the ubiquitous protocol on which the Internet runs. Logically, two machines communicate through IP datagrams, which are then sent over the link layer as packets. Runs on top of link layers like Ethernet, Packet over SONET or ATM. Defined in IETF RFC791 & STD5. LANE (Local Area Network Emulation): LANE is a method for emulating Ethernet behavior over ATM AAL5. It takes over the behavior of the MAC layer in Ethernet networks. LLC (Logical Link Control): The LLC method allows multiplexing of multiple protocols over a single ATM VC. LLC headers are 3 bytes.
Zarlink Semiconductor Inc.
185
MT92210
Data Sheet
MAC (Media Access Control): The MAC layer is concerned with the control of access to a medium shared between two or more entities. It is a control layer for Ethernet. OC-3 (Optical Carrier level-3): A SONET channel that carries a bandwidth of 155.55 Mbps. Packet: The "data" unit carried on a link layer. A packet, on an IP network, consists of an entire IP datagram or a fragment of a datagram. PCM (Pulse Code Modulation): PCM is the basic method of encoding an analog voice signal into digital form using 8-bit samples. Defined by the ITU standard G.711. PHY (PHYsical layer) PLL (Phase Lock Loop): A phase lock loop is a component that generates an output clock by synchronizing itself to an input clock. PLLs are often used to multiply the frequency of clocks. POS (Packet Over SONET): A means of transporting packets over a SONET link with minimal overhead in a point-to-point connection. POS uses PPP as its link protocol. POS-PHY: A bus standard for connecting Packet Over SONET link layer devices to PHYsical layer ones. POS-PHY level 2 was based loosely on UTOPIA level 2. POTS (Plain Old Telephone Service): The ubiquitous, 64 kbps phone service widely deployed in today's phone networks. PPP (Point-to-Point Protocol): A link protocol that allows for transport of many network protocols over a point-to-point link. PPP has very little overhead (1 or 2 bytes per packet), making it very attractive for some applications. RAM (Random Access Memory): RAM is the main memory in the computer. It is called "random" because any random address can be accessed in an equal amount of time. RTCP (Real-Time Control Protocol): The control protocol for RTP, RTCP is used for control and diagnostic on RTP sessions. Like RTP, RTCP typically runs on top of UDP and is defined in the IETF RFC1889. RTP (Real-Time Protocol): A transport protocol designed to provide end-to-end delivery services for data with real-time characteristics. RTP typically runs on top of UDP. Defined in the IETF RFC1889. SNAP (Sub Network Access Protocol): A SNAP header consists of 5 bytes, three bytes of OUI (Organizationally Unique Identifier) and 2 bytes of PID (Protocol IDentifier). The OUI defines which organization administers the PID that follows. The value of 000000h in the OUI means that the PID is defined as an EtherType. TCP (Transmission Control Protocol): A transport layer, TCP is a highly reliable host-to-host protocol that guarantees packet delivery, non-duplicated and in order. TCP runs on top of IP. Defined in IETF RFC791 & STD7. TDM (Time Division Multiplexing): TDM busses carry voice data divided according to frames. In a single 125 us frame, the TDM bus will have carried one byte from each channel it contains. UDP (User Datagram Protocol): A transport layer, UDP provides a protocol for applications to communicate with a minimum of overhead. UDP does not guarantee packet delivery or ordering. UDP runs on top of IP. Defined in IETF RFC768 & STD6. UTOPIA (Universal Test and OPerations Interface for ATM): The electrical interface on which ATM cells are passed. VC (Virtual Circuit): VC define a point-to-point connection between two nodes in a network. A single ATM cell carries data that belongs to a single VC. VCI (Virtual Channel Identifier): This is the label given to an ATM VC to identify it and determine its destination. The VCI is a 16-bit number that is included in the header of an ATM cell. VPI (Virtual Path Identifier): A virtual path determines the way an ATM cell should be routed. The VPI is an 8-bit (in UNI) or 12-bit (in NNI) number that is included in the header of an ATM cell. WATOMIC: An uninterruptable Write operation.
186
Zarlink Semiconductor Inc.
Data Sheet
Terms Specific to This Specification
MT92210
Bearer: A unidirectional xxPCM stream. In PCM A-law or u-law, a single bearer will have a bandwidth of 64 kbps; this bandwidth will be reduced in ADPCM. In this device, a single PCM channel may interleave many bearers. Channel: A data stream of a given nature mapped over a connection is considered a channel. For example, a PCM data stream mapped over an RTP connection would be a single channel, even if that data stream interleaved more than 1 bearer in each packet. In like manner, any set of payload types that are all destined to the same HDLC endpoint would also be considered a channel. Connection: A link between two end-points that is unique through some look-up method, either through source & destination IP addresses and UDP ports, through those plus RTP SSRC, or through ATM VC number and possibly RTP SSRC on Null-application data VC. HDLC Stream: A group of HDLC channels that are carried over the same time slots. HDLC mini-packets in streams have an address byte that indicates to which HDLC channel they belong. Usually, HDLC streams carry a series of channels communicating to and from the same agent (e.g. a DSP). HDLC Streams may be carried over one or multiple consecutive time-slots on the H.100 bus. This device supports streams of length 1 to 2046 time slots. PDV: Packet Delay Variation. RTP packets arrive with a certain delay with respect to when they were sent. PDV is a measure of how much that delay varies on an xxPCM channel. PDV measures the peak-to-peak packet delay throughout the network. PDV is only relevant on CBR connections. Time Slot: In this document, the term time slot is often used to define a combination of a time slot and a stream on the H.100 bus. Thus a time slot would represent a single 8-bit slot every 125 us on the TDM bus. Time slot/Stream numbers are numbered 0 to 4095 according to the following equation: time slot * 32 + stream. On reduced-frequency TDM streams, certain time slots become unusable. For streams running on a 4 MHz clock, time slots are numbered 0 to 63, and the equations to determine TSSTs are the following: in the TX TDM, TSST = (time slot * 2 + 1) * 32 + stream, and in the RX TDM, TSST = (time slot * 2) * 32 + stream. In like manner, for streams running on a 2 MHz clock, time slots are numbered 0 to 31, and the equations are: in the TX TDM, TSST = (time slot * 4 + 3) * 32 + stream, and in the RX TDM, TSST = (time slot * 4) * 32 + stream. "Null" VC: A Null VC contains data in which some or all of the headers have been encoded into the VC number itself. For example, a Null-application data VC's payload would begin with the application data itself (either RTP or the payload) with no IP or UDP header, and no SNAP/LLC, LANE or other headers. Null encapsulation is referred to in IETF RFC2684 as VC Multiplexing.
Zarlink Semiconductor Inc.
187
MT92210
Data Sheet
188
Zarlink Semiconductor Inc.
DIMENSION
E/4
D/4
MIN NOM MAX A ----2.50 A1 0.40 ----A2 0.25 --0.70 A3 ----1.25 D 31.00 BSC D1 25.00 --27.00 E 31.00 BSC E1 25.00 --27.00 b 0.50 --0.70 e 1.00 BSC F 20.50 --22.50 N 608 Conforms to JEDEC MS - 034 Rev. A
NOTES:
1. ALL DIMENSIONS AND TOLERANCES CONFORM TO ASME Y14.5M-1994. 2. ALLDIMENSIONS ARE IN MM. 3. CORNER DETAIL IS LSI LOGIC CORP OPTION. 4. DETAILS OF PIN 1 IDENTIFIER ARE OPTIONAL, AND MAY CONSIST OF INK, LASER MARK OR METALLIZED MARKING, BUT MUST BE LOCATED WITHIN THE INDICATED ZIONE. 5. PRIMARY DATUM Z AND SEATING PLANE ARE DEFINED BY THE SPHERICAL CROWNS OF THE SOLDER BALLS. 6. HEAT SPREADER OUTLINE.
Package Code
ISSUE ACN DATE APPRD.
Previous package codes:
For more information about all Zarlink products visit our Web Site at
www.zarlink.com
Information relating to products and services furnished herein by Zarlink Semiconductor Inc. trading as Zarlink Semiconductor or its subsidiaries (collectively "Zarlink") is believed to be reliable. However, Zarlink assumes no liability for errors that may appear in this publication, or for liability otherwise arising from the application or use of any such information, product or service or for any infringement of patents or other intellectual property rights owned by third parties which may result from such application or use. Neither the supply of such information or purchase of product or service conveys any license, either express or implied, under patents or other intellectual property rights owned by Zarlink or licensed from third parties by Zarlink, whatsoever. Purchasers of products are also hereby notified that the use of product in certain ways or in combination with Zarlink, or non-Zarlink furnished goods or services may infringe patents or other intellectual property rights owned by Zarlink. This publication is issued to provide information only and (unless agreed by Zarlink in writing) may not be used, applied or reproduced for any purpose nor form part of any order or contract nor to be regarded as a representation relating to the products or services concerned. The products, their specifications, services and other information appearing in this publication are subject to change by Zarlink without notice. No warranty or guarantee express or implied is made regarding the capability, performance or suitability of any product or service. Information concerning possible methods of use is provided as a guide only and does not constitute any guarantee that such methods of use will be satisfactory in a specific piece of equipment. It is the user's responsibility to fully determine the performance and suitability of any equipment using such information and to ensure that any publication or data used is up to date and has not been superseded. Manufacturing does not necessarily include testing of all functions or parameters. These products are not suitable for use in any medical products whose failure to perform may result in significant injury or death to the user. All products and materials are sold and services provided subject to Zarlink's conditions of sale which are available on request.
Purchase of Zarlink's I2C components conveys a licence under the Philips I2C Patent rights to use these components in an I2C System, provided that the system conforms to the I2C Standard Specification as defined by Philips. Zarlink and the Zarlink Semiconductor logo are trademarks of Zarlink Semiconductor Inc. Copyright 2002, Zarlink Semiconductor Inc. All Rights Reserved.
TECHNICAL DOCUMENTATION - NOT FOR RESALE

▲Up To Search▲

Price & Availability of MT92210

	To Download MT92210 Datasheet File
If you can't view the Datasheet, Please click here to try to view without PDF Reader .